benchmarks 2020-12-25See original GitHub issue
i finally spent some time on a new round of benchmarks with updated libs & updated Chrome. top is previous round, bottom is current standings:
- improvements to Chrome have boosted quite a few numbers, in some cases rather drastically. e.g. Flot perf doubled and dygraphs became significantly faster despite no lib or bench changes to either.
- apex seems to have regressed their mousemove/tootltip performance a ton
- uplot is now even faster due to simplification of the linear path-building code and completely extracting + rethinking the bands rendering logic.
let’s talk about ECharts v5 – holy shit. it went from fourth-to-last to second place. that
LTTB sampling, dense array packing and whatever other black magic is going on made it fly. what’s worrying about this is that this lib is almost 1MB (30x larger than uPlot), yet the initial parse/compilation does not seem to have that large an effect, even when reloading with caching disabled in devtools. since these measurements are taken from close-to-best runs, i think that there is still a JIT cache that persists, and chrome simply uses the content hash to revive the prior compiled bytecode. i tried to record a few runs from an
about:blank page and it seemed to confirm that there is some caching going on that cannot be disabled from devtools, though it is not as drastic as i expected – a cold boot is about 360ms vs 435ms cumulative - a 75ms difference, which is less than the difference when running with what i assume is a warm JIT cache. i honestly have no idea where exactly parsing and JITing an extra 900KB of JS is accounted for, and it scares me that i’m doing something wrong or devtools is lying to me. if someone has any idea what’s going on, please clue me in! either way, the results are nothing short of astounding, so massive props to @pissang.
- Created 3 years ago
- Comments:11 (6 by maintainers)