V5 vs V6

What Changed In V6

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

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 100 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.