Best Mount Improvement
+ + {formatDeltaMs(strongestMountWin.mountDeltaMs)} + ++ v6 mounts fastest relative to v5 at {strongestMountWin.count.toLocaleString()}{' '} + anchors in the current snapshot. +
+
+
+
+
+
+
+
+
+
+
+
+ Best Memory Reduction
+ + {formatMemory(strongestMemoryWin.mountMemDeltaKiB)} + ++ v6 retains less mount-time memory than v5 at{' '} + {strongestMemoryWin.count.toLocaleString()} anchors. +
+Highest Tested Workload
+ {largestRow.count.toLocaleString()} ++ Largest published scenario in this benchmark snapshot. +
+
+
+
+
+
+
+ What Changed In V6
++ The current snapshot shows a cleaner result than the earlier runs: v6 now trends + lower on mount time, lower on unmount time, and lower on mount memory across the + full range of tested workloads. +
++ The v6 work keeps the existing feature surface while reducing the internal cost of + supporting it. Most of the gains come from removing repeated work and making + high-frequency runtime paths cheaper. +
+-
+
- + Shared anchor discovery and tracking: anchor-related state is + centralized instead of repeated per tooltip instance. + +
- + Delegated event handling: the implementation avoids attaching + redundant listeners across many anchors. + +
- + Less per-anchor bookkeeping in hot paths: costs that used to + scale with anchor volume are reduced where they matter most. + +
+ These changes matter most under load. At small counts, repeated work can hide + behind fixed overhead. As the workload grows, the cost of duplicated tracking, + redundant listeners, and per-anchor work becomes visible. +
+ +What The Benchmark Measures
++ Each row compares the same scenario in v5 and v6. Anchor count is the workload + variable, but the benchmark itself is a version-to-version runtime comparison. +
+-
+
- + Mount time: the cost of initializing tooltip behavior for the + scenario. + +
- + Unmount time: the cost of tearing that setup down. + +
- + Mount memory: the memory retained while initialization is + happening. + +
+ These metrics map to practical frontend concerns. Mount cost affects render, + hydration, and large UI updates. Memory retention matters because tooltip state + stays resident after setup, especially when many anchors are active on the same + page. +
+
+
+ Benchmark Results
+
+
+
+
+
+ | Anchors | +V5 Mount | +V6 Mount | +Mount Delta | +Mount Variation | +V5 Unmount | +V6 Unmount | +Unmount Delta | +Unmount Variation | +V5 Mount Mem | +V6 Mount Mem | +Mount Mem Delta | +Mount Mem Variation | +
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| {row.count.toLocaleString()} | +{row.v5MountMs.toFixed(2)} ms | +{row.v6MountMs.toFixed(2)} ms | ++ {formatDeltaMs(row.mountDeltaMs)} + | ++ {formatPercent(row.mountSpreadPercent)} + | +{row.v5UnmountMs.toFixed(2)} ms | +{row.v6UnmountMs.toFixed(2)} ms | ++ {formatDeltaMs(row.unmountDeltaMs)} + | ++ {formatPercent(row.unmountSpreadPercent)} + | +{formatMemory(row.v5MountMemKiB)} | +{formatMemory(row.v6MountMemKiB)} | ++ {formatMemory(row.mountMemDeltaKiB)} + | ++ {formatPercent(row.mountMemSpreadPercent)} + | +
+ Delta compares v5 and v6 for the same scenario.
+ Variation reflects how much repeated runs moved for that metric
+ across repeated runs of the same scenario.
+ Spread shows how stable the metric was across repeated runs.
+
+ Each row summarizes {benchmarkSnapshot.inputFiles} benchmark runs for the same + scenario. It shows the aggregated result for v5 and v6 at that workload size, + along with the delta between versions and the run-to-run variation for each + metric. +
+
+
+ Why Mount Metrics Matter Most
++ Mount behavior is the most useful signal here because it represents the cost of + enabling tooltip behavior in the first place. +
++ That cost shows up during page load, hydration, and large UI updates. If setup is + expensive, users pay for it immediately through slower render work and slower + interaction readiness. +
++ Lower mount time reduces that blocking work and lower mount memory reduces the + steady overhead that remains after initialization. +
+ +Why Unmount Metrics Need More Care
++ Unmount data still matters, but cleanup timing is more sensitive to browser + scheduling, deferred work, and memory reclamation behavior. +
++ For that reason, unmount measurements work better as supporting evidence than as + the primary basis for declaring one version faster. +
+ +The Memory Metrics
++ In the current snapshot, v6 is lower on mount memory at every tested workload. + That means the implementation is not only doing less work during initialization, + but also carrying less state while doing the same job. +
++ The importance of that difference increases with density. Small memory wins at low + counts are easy to dismiss. The same pattern at higher counts is much more + consequential. +
+
+
+ Finally
++ Across the full range of tested workloads, v6 mounts faster, unmounts faster, and + retains less memory than v5. +
+ ++ For the full migration surface between v5 and v6, including API changes and new + capabilities, check the{' '} + v5 → v6 changelog. +
+