[turbofan] Bump the fast literal properties budget for JSCreateLowering.

[turbofan] Bump the fast literal properties budget for JSCreateLowering.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of JSCreateLiteralObject nodes in TurboFan
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

R=jarin@chromium.org
BUG=v8:6211
Review-Url: https://codereview.chromium.org/2805613002
Cr-Commit-Position: refs/heads/master@{#44424}
Committed: https://chromium.googlesource.com/v8/v8/+/bff3b266d23cf0054e687b150f949acc6ce2e1a9

[Benedikt Meurer, 2017-04-06 05:35:27]

The CQ bit was checked by bmeurer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 05:35:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Jarin, 2017-04-06 05:44:19]

lgtm

[Benedikt Meurer, 2017-04-06 05:44:28]

The CQ bit was unchecked by bmeurer@chromium.org

[Benedikt Meurer, 2017-04-06 05:44:32]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2017-04-06 05:44:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-06 06:00:54]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1491457472631910, "parent_rev":
"547dd0bcb1c32ba59cebc88f2dcf688f3c72b0c4", "commit_rev":
"bff3b266d23cf0054e687b150f949acc6ce2e1a9"}

[commit-bot: I haz the power, 2017-04-06 06:01:13]

Description was changed from

==========
[turbofan] Bump the fast literal properties budget for JSCreateLowering.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of JSCreateLiteralObject nodes in TurboFan
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

R=jarin@chromium.org
BUG=v8:6211
==========

to

==========
[turbofan] Bump the fast literal properties budget for JSCreateLowering.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of JSCreateLiteralObject nodes in TurboFan
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

R=jarin@chromium.org
BUG=v8:6211

Review-Url: https://codereview.chromium.org/2805613002
Cr-Commit-Position: refs/heads/master@{#44424}
Committed:
https://chromium.googlesource.com/v8/v8/+/bff3b266d23cf0054e687b150f949acc6ce...
==========

[commit-bot: I haz the power, 2017-04-06 06:01:14]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/v8/v8/+/bff3b266d23cf0054e687b150f949acc6ce...