A few conversations have circled around user-side structural profiling. For context, see React PR #7549: Show React events in the timeline when ReactPerf is active
One particular concern is the measurement overhead. This gist has a benchmarking script (measure.js
) for evaluating overhead and initial results.
Runs about 0.65µs per mark()
call. Naturally, that's ~= an overhead of 1ms for 1500 mark()
s.
Calls to measure()
are not significantly more expensive than calls to mark()
. They appears to be ~30% more expensive than a mark()
, but still only clocking in at ~0.85µs per measure()
call.
(If benchmarking, be sure to run timeline against your benchmark; I've seen large DOM GC's when calling measure >50,000 times a second. :)
console.time
is much more expensive at ~11.5 µs/call (thats ~18x slower than perf.mark()). Therefore, it's not recommended. Also it spams your console, so it's inconvenient to use for high-volume work.
Hey Paul, a question about:
Wouldn't a mature implementation of
measure()
do it's work lazily, outside of the critical path? Why is use code in a better position to defer the expensive parts ofmeasure()
?