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
