[crankshaft] Bump the fast literal properties budget.

[crankshaft] Bump the fast literal properties budget.

Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.

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 object literal nodes into Crankshaft
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).

TBR=jarin@chromium.org
BUG=v8:6211
Review-Url: https://codereview.chromium.org/2800053002
Cr-Commit-Position: refs/heads/master@{#44464}
Committed: https://chromium.googlesource.com/v8/v8/+/12ab9484ee6ae479ec1f929b943bd63d5ef80f3c

[Benedikt Meurer, 2017-04-07 04:10:39]

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

[commit-bot: I haz the power, 2017-04-07 04:10:42]

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

[Benedikt Meurer, 2017-04-07 04:11:23]

The CQ bit was unchecked by bmeurer@chromium.org

[Benedikt Meurer, 2017-04-07 04:11:28]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2017-04-07 04:11:32]

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-07 04:35:26]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1491538288718750, "parent_rev":
"98d5bc6b637bbc52b5dfba359790bea950a0ee7f", "commit_rev":
"12ab9484ee6ae479ec1f929b943bd63d5ef80f3c"}

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

Description was changed from

==========
[crankshaft] Bump the fast literal properties budget.

Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.

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 object literal nodes into Crankshaft
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).

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

to

==========
[crankshaft] Bump the fast literal properties budget.

Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.

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 object literal nodes into Crankshaft
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).

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

Review-Url: https://codereview.chromium.org/2800053002
Cr-Commit-Position: refs/heads/master@{#44464}
Committed:
https://chromium.googlesource.com/v8/v8/+/12ab9484ee6ae479ec1f929b943bd63d5ef...
==========

[commit-bot: I haz the power, 2017-04-07 04:35:34]

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