On Fri, Jun 16, 2017 at 2:08 PM, Jan de Mooij <jdemo...@mozilla.com> wrote:
> Objects are already nursery allocated, so that's probably why ArrayBuffer > is faster. > Sorry, I think ArrayBuffers are not nursery allocated right now, so allocating a ton of them would also trigger major GCs. Also note that we have an external string cache (see ExternalStringCache::lookup), it compares either the char pointers or the actual characters (if length <= 100). If we are returning the same strings (same characters) all the time on this benchmark, you could try removing that length check to see if it makes a difference. Jan > > 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
