My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 148757: postMessage is very slow with Javascript objects
24 people starred this issue and may be notified of changes. Back to list
Reported by, Sep 12, 2012
Chrome Version       : 22.0.1229.39
OS Version: 
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?
1. Unzip the attached file
2. Start Chrome with --allow-file-access-from-files
3. Open the file in test.html
4. Look for results in the console

What is the expected result?
The time for "largeObj" should be comparable to Firefox or Safari.  On my machine it is more than 10x slower.

What happens instead?

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.39 Safari/537.4
91.2 KB   Download
Sep 12, 2012
I ran the test on the same box with Firefox, Safari and Chrome.  The results for the largeObj tests were:

Firefox:     429ms
Safari:      630ms
Chrome:     7125ms

Sep 12, 2012
(No comment was entered for this change.)
Labels: Hotlist-GoogleApps
Sep 14, 2012
(No comment was entered for this change.)
Status: Assigned
Labels: -Area-Undefined Area-WebKit Mstone-24
Sep 14, 2012
(No comment was entered for this change.)
Oct 3, 2012
@dimich, have you had an opportunity to take a look at this, by chance? Rounding up updates for open Chrome/Apps hotlist bugs. Thanks!
Oct 17, 2012
(No comment was entered for this change.)
Oct 22, 2012
(No comment was entered for this change.)
Nov 8, 2012
(No comment was entered for this change.)
Nov 8, 2012
After some profiling, I found that more than half of the time is spent in
(value->IsNativeError()) check in

Commenting out that check reduces largeObj time from 2500ms to 1200ms on my machine. So there might be some potential in speeding up the IsNativeError function.
Nov 12, 2012
I landed a change in V8 bleeding edge that speeds up the IsNativeError function ( The largeObj time on my machine goes down from 2500ms to 1300ms.
Nov 15, 2012
(No comment was entered for this change.)
Nov 28, 2012
Sounds like we've made a lot of great progress. Is there still more work to do, or should we close this bug?
Jan 22, 2013
(No comment was entered for this change.)
Jan 31, 2013
Changing the milestone to M26 for now. Please change it to the appropriate milestone.
Labels: -Mstone-24 Mstone-26 MovedFrom-24
Feb 18, 2013
From testing on a build of M26, it still seems like JSON.parse is somewhat slower than eval (slightly).  Is this expected? I would have guessed we could make JSON.parse faster than eval.  In FF it is faster than eval.

Feb 19, 2013
(No comment was entered for this change.)
Feb 27, 2013
IIRC, Noel did some work here recently, or at least had notified me about strings being slow.  CCing him in case he has comment.
Feb 27, 2013
Honestly, we should just write some simple run-perf-test microbenchmarks in WebKit's PerformanceTests framework, and track this via  This is a great candidate for microbenchmarking.

run-perf-tests is the script to run webkit's PerformanceTests microbenchmarks and has useful options like --profile which will automatically run your OS-relevant sampling profiler to help you debug the perf problem.
Feb 28, 2013
(No comment was entered for this change.)
Mar 1, 2013
Is the problem here that Chrome runs WebWorkers in separate processes rather than in separate threads like Safari and Firefox, and as a result incurs extra overhead from copying the data across the process boundaries?  We've written some code that uses "transferable objects" instead of JSON serialization, and it's still disappointingly slow, despite the cost of transferable objects allegedly being a "zero-copy operation" (Source:
Is this something that's fixable or is just an inherent limitation of Chrome's design?

For our work, the slow performance of postMessage makes WebWorkers unusable and means that Chrome doesn't really have viable multi-core support (again, for our purposes).

On a related note, it would be nice if the WebWorker spec were modified to allow for zero-copy sharing of frozen objects (JS objects have a freeze() method which makes them immutable, but perhaps we would also add a deepFreeze() method).  If you could either share or transfer frozen objects between WebWorkers without any coping costs, then Chrome would have useful concurrency support (for my purposes). 
Mar 1, 2013
I may be wrong but I don't think the cross-process issue is the crux of the problem, or at least I suspect there is still quite a lot of optimization that can be done (for instance we're byteswapping the entire buffer (i.e. ntohs/htons of every 2 bytes) on both ends before/after the serialization... ( plus I suspect that we are also copying the whole serialized value at least one or two times unnecessarily on each end prior to / after the IPC calls. (I say this only because I found 4-5 extra copies in the IDB code that similarly transfers SerializedScriptValues across the process boundaries, and that gave us a noticeable performance improvement)

Until we solve those problems, I don't think we can really evaluate if lower-level v8 freezing is an obvious improvement or not.
Mar 1, 2013
alecflett@, My suggestions for cheap sharing of frozen objects was meant as an idea for longer-term consideration, while we were on the topic, but I agree that the problem at hand really needs a solution in the short-term.  Hopefully it isn't a cross-process issue and can be fixed through optimization.
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-WebKit -Mstone-26 Cr-Content M-26
Apr 3, 2013
Bulk edit: Moving non-release blocking bugs to M28
Labels: -M-26 M-28 MovedFrom-M26
Apr 4, 2013
Is there an ETA on this bug?  

It keeps getting bumped to the next release.  It's been in the queue for over six months.
Apr 4, 2013
Tim, there have been a number of improvements in the past few months. That said, there's still more room for improvement, which is why the bug isn't closed.
Apr 5, 2013
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
May 8, 2013
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Labels: -M-28 MovedFrom-28
May 21, 2013
The slowness of SerializedScriptValue can be tested without even involving workers:

window.postMessage(largeObj, '*')

reproduces the slowness.
May 21, 2013
(No comment was entered for this change.)
Aug 15, 2013
Adam, any chance you've been able to look into this?
Aug 15, 2013
I did look into this when I assigned it to myself, but didn't make any headway in speeding it up. My hunch is that we might want to move SerializedScriptValue-handling into V8 somehow, since I think the overhead of going through the API is hurting us on speed. But that would also require hooks back into the embedder to deal with the host objects that can be cloned, and it's not clear you'd still have the speed gains after making those calls.

Unassigning from myself for now, as I don't have the bandwidth to work on this at the moment.
Status: Available
Owner: ---
Aug 21, 2013
(No comment was entered for this change.)
Oct 23, 2013
(No comment was entered for this change.)
Labels: -Hotlist-GoogleApps
Mar 17, 2014
On my Version 33.0.1750.154 m
Works slowly than same code on FF (work as expected)

It's looking as stuck for a little and then starting to work.

Used Heap Size: 20.8 MB (+9.5 KB)
100-150 ms

Sign in to add a comment

Powered by Google Project Hosting