The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/a7ecf7d4ee542f5c6e1819d94e1aa3ab04081ff1

commit a7ecf7d4ee542f5c6e1819d94e1aa3ab04081ff1
Author: Toon Verwaest <verwaest@chromium.org>
Date: Wed Oct 04 15:01:29 2017

Inline relevant parts of MigrateToMap into AllocateStorageForMap

This speeds up the json parser by 10-20%

Bug: chromium:771227
Change-Id: Ib2392471bdd9ff9041237708cb272229b5ece410
Reviewed-on: https://chromium-review.googlesource.com/700494
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48287}
[modify] https://crrev.com/a7ecf7d4ee542f5c6e1819d94e1aa3ab04081ff1/src/objects.cc

Thanks! I just tested today's canary which contains your improvement, here are some numbers:

Time:
values 11.981141682990975, 11.848341232227492, 11.803031018365512, 11.970456912340339, 11.977697527204342, 11.810558639423647, 11.372165487752175, 11.787170843254188, 12.060616659329785, 11.500730296373817, 11.982649124068363, 11.901503159849096, 11.973323435385979, 12.018075185078333, 11.947574045090121, 12.012372743926239, 11.859512218262465, 11.862959096517022, 12.0500801330329, 12.048120192047021 runs/s
avg 11.888403981625988 runs/s
median 11.95901547871523 runs/s
stdev 0.17771026565578585 runs/s
min 11.372165487752175 runs/s
max 12.060616659329785 runs/s

Also, the perf dashboard for speedometer's VanillaJS shows an improvement for Linux and Mac (Windows didn't change much, and I can confirm on my windows box that there wasn't an improvement -- hopefully this will change with clang on windows).

https://chromeperf.appspot.com/report?sid=7e09cfe84f43452952e6a3220140c2b9658d0643de47d2ff2ac3e89d4c3df93b

For what it's worth, the change in #2 is also a 20% speedup in the structured deserializer (postMessage etc.), which is similar to the JSON parser. Awesome work!

Forgot the graph link:
https://chromeperf.appspot.com/report?sid=6b77e7e0e31d8901b0a6e2e51b9c2a65ca1a48c22b07879172f4dd778c16f7cc

I've got a few ideas for relatively-micro stuff that might squeeze another bit out of here.

What exactly? I've put optimizing the JSON parser on marja's plate. She'll look into replacing the recursive descent parser with a tight loop using a single zone stack (instead of multiple zonelists).

Ah, I wasn't aware Marja was going to look at this.

I have a CL to avoid reallocating the properties ZoneVector by using a single ZoneVector stack for the entire time:
https://chromium-review.googlesource.com/c/v8/v8/+/789511

(And a similar trick for elements seems useful, even though it doesn't matter for the Speedometer case.)

I was also going to look at shuffling around when the JSObject is actually created, since doing the allocation and then later the AllocateStorageForMap seems to be slower than just doing the allocation with the final map (at least for the transitioning fast path). I've done a little poking at that, but haven't polished a CL yet.

I'm sure a deeper look at improving the parser loop would yield results; I don't mean to interfere with such work.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/d3104923b24180d32747287ba51b41e4af8b0da7

commit d3104923b24180d32747287ba51b41e4af8b0da7
Author: Jeremy Roman <jbroman@chromium.org>
Date: Tue Nov 28 22:53:50 2017

Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties.

The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.

This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.

This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.

Bug: chromium:771227
Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
Reviewed-on: https://chromium-review.googlesource.com/789511
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49693}
[modify] https://crrev.com/d3104923b24180d32747287ba51b41e4af8b0da7/src/json-parser.cc
[modify] https://crrev.com/d3104923b24180d32747287ba51b41e4af8b0da7/src/json-parser.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/32033f4f4fdf96986a32d9fd97da5cacd814795c

commit 32033f4f4fdf96986a32d9fd97da5cacd814795c
Author: Michael Achenbach <machenbach@chromium.org>
Date: Wed Nov 29 10:57:48 2017

Revert "Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties."

This reverts commit d3104923b24180d32747287ba51b41e4af8b0da7.

Reason for revert: Breaks win debug, causes lots of timeouts.
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/20387

Original change's description:
> Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties.
> 
> The parser holds a single vector whose backing storage is reused in calls
> to ParseJsonObject, so that once we reach the peak number of unstored
> properties no more allocations are required.
> 
> This improves performance of parsing inputs like those in Speedometer VanillaJS
> by about 2% in my local measurement, and would presumably do better on more
> pathological inputs.
> 
> This should also have the side effect of reducing peak memory usage at this time
> slightly, since we do fewer zone allocations which cannot be freed until the
> parse finishes.
> 
> Bug: chromium:771227
> Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
> Reviewed-on: https://chromium-review.googlesource.com/789511
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Jeremy Roman <jbroman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49693}

TBR=jbroman@chromium.org,marja@chromium.org,cbruni@chromium.org

Change-Id: I5b198aeffed6f1543f6110709dc74b311d4ba144
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771227
Reviewed-on: https://chromium-review.googlesource.com/796151
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49705}
[modify] https://crrev.com/32033f4f4fdf96986a32d9fd97da5cacd814795c/src/json-parser.cc
[modify] https://crrev.com/32033f4f4fdf96986a32d9fd97da5cacd814795c/src/json-parser.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/d01428579cdf65eba2b0a2ff1d989bbe16f44608

commit d01428579cdf65eba2b0a2ff1d989bbe16f44608
Author: Jeremy Roman <jbroman@chromium.org>
Date: Mon Dec 11 15:30:55 2017

Reland: Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties.

The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.

This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.

This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.

Reland switches to use std::vector::data instead of operator[] to avoid an index
check in debug MSVC. In such cases the out-of-bounds pointer cannot be
dereferenced, so it is legal.

Bug: chromium:771227
Change-Id: I21837196372c904bfc799cd14353a73d11dcff32
Reviewed-on: https://chromium-review.googlesource.com/804062
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49997}
[modify] https://crrev.com/d01428579cdf65eba2b0a2ff1d989bbe16f44608/src/json-parser.cc
[modify] https://crrev.com/d01428579cdf65eba2b0a2ff1d989bbe16f44608/src/json-parser.h