Overhead of returning a string from C++ to JS over WebIDL bindings

I noticed a huge performance difference between
https://hsivonen.com/test/moz/encoding_bench_web/ and
https://github.com/hsivonen/encoding_bench/ . The former has the
overhead of JS bindings. The latter doesn't.

On a 2009 Mac Mini (Core 2 Duo), in the case of English, the overhead
is over twice the time spent by encoding_rs in isolation, so the time
per iteration over triples!

The snowman test indicates that this isn't caused by SpiderMonkey's
Latin1 space optimization.

Safari performs better than Firefox, despite Safari using ICU (except
for UTF-8 and windows-1252) and ICU being slower than encoding_rs in
isolation on encoding_bench (tested on Linux). Also, looking at
Safari's UTF-8 and windows-1252 decoders, which I haven't had the time
to extract for isolated testing, and Safari's TextDecoder
implementation, there's no magic there (especially no magic compared
to the Blink fork of the UTF-8 and windows-1252 decoders).

My hypothesis is that the JSC/WebKit overhead of returning a string
from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the
V8/Blink overhead. (When encoding from string to ArrayBuffer, Safari
doesn't have the advantage, which is also suggestive of this not being
a matter of how GC happens relative to the timed runs.)

Do we know why?

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/
0
Henri
6/16/2017 11:22:42 AM
mozilla.dev.platform 5751 articles. 0 followers. Post Follow

1 Replies
12 Views

Similar Articles

[PageSpeed] 11

On 6/16/17 7:22 AM, Henri Sivonen wrote:
> My hypothesis is that the JSC/WebKit overhead of returning a string
> from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the
> V8/Blink overhead.

It definitely is.  JSC and WebKit use the same exact refcounted strings, 
last I checked, so returning a string from WebKit to JSC involves a 
single non-atomic refcount increment.  It's super-fast.

-Boris
0
Boris
6/16/2017 8:19:49 PM
Reply: