I profiled this quickly and we're spending a lot of time in GC. Nursery allocating strings (bug 903519) is going to help a lot here as it will make both string allocation and GC much faster. Objects are already nursery allocated, so that's probably why ArrayBuffer is faster.
We create external strings (a JS string referencing a DOM string buffer) for the strings returned from DOM to JS and in my profiles I don't see us spending a lot of time on this. More than 70% of the time is in encoding_rs. It may be different for other parts of the benchmark - it would be nice to have a minimal testcase showing the problem. Hope this helps, Jan On Fri, Jun 16, 2017 at 1:22 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > 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 > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
