Chrome DevTools性能火焰图时间分辨率疑问：0.16ms是真实耗时还是最小精度？
Great question—this is a super common gotcha with Chrome DevTools' performance profiler! Let's break this down clearly:
First off: Those 0.16ms values are not the actual exact runtime of each task—they represent the minimum time resolution of the profiler's default sampling mode.
Here's the background: By default, DevTools uses a sampling-based profiler that takes a snapshot of the JavaScript call stack approximately every 0.16ms (that’s 6000 samples per second). When a function is caught "in the act" during one of these snapshots, it gets a 0.16ms block in the flame graph—even if it only ran for a tiny fraction of that time.
This is a deliberate tradeoff: Sampling mode is lightweight (it adds barely any overhead to your running code), making it perfect for spotting broad performance hotspots across your app. But it can’t capture the exact duration of ultra-short functions—anything faster than the sampling interval will just show up as 0.16ms.
If you need precise timings for these small tasks, you can switch to the instrumentation-based profiling mode (look for this option in the performance panel’s settings, usually near the record button). This mode injects tiny tracking code snippets to log the exact start and end time of every function call. It’s far more accurate but adds noticeable runtime overhead, so save it for targeted debugging of short-lived operations.
A quick way to confirm this behavior: If you see a function that runs longer than 0.16ms, it’ll show up as multiple stacked 0.16ms blocks (or a single longer block if it spans multiple samples). That’s a dead giveaway the profiler is aggregating samples rather than reporting exact runtime.
内容的提问来源于stack exchange，提问作者Robert Hönig
