bench: add a representative concat sourcemap benchmark#369
Conversation
Merging this PR will degrade performance by 1.03%
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing Footnotes
|
#366 switched `ConcatSourceMapBuilder` to borrowed `&'a str` storage, which is optimal when inputs outlive the result. But its main consumer (rolldown's `SourceJoiner`) feeds *owned* `SourceMap<'static>` maps and wants an owned map back, so `into_owned_sourcemap` deep-copied every name/source/sourcesContent string — and `sourcesContent` is the full module text. Store entries as `Cow<'a, str>` again so the builder can absorb owned strings by moving them, and add: * `add_sourcemap_owned(SourceMap<'a>, u32)` / `from_owned_sourcemaps(..)` — consume owned maps and move their `Cow` entries in (no string bytes copied). * `add_sourcemap` (borrowed) and `add_sourcemap_owned` now share an `add_tokens` helper; only how the strings get in differs. `into_sourcemap` moves the accumulated vectors straight out (also cheaper than #366's rebuild for the borrowed case); `into_owned_sourcemap` keeps moved-in owned strings as-is and copies only borrowed ones. The `concat/owned_maps` benchmark (added in #369 as the borrow baseline) is switched to the move-in path here. From the investigation sweep (200 modules): move-in is flat at ~32us regardless of `sourcesContent` size, while borrow + `into_owned_sourcemap` grows linearly (37us @256b, 47us @2KB, 70us @8kb, 542us @32kb) — up to ~16x faster, identical mappings output.
|
Adds the borrow-path baseline benches: |
#366 switched `ConcatSourceMapBuilder` to borrowed `&'a str` storage, which is optimal when inputs outlive the result. But its main consumer (rolldown's `SourceJoiner`) feeds *owned* `SourceMap<'static>` maps and wants an owned map back, so `into_owned_sourcemap` deep-copied every name/source/sourcesContent string — and `sourcesContent` is the full module text. Store entries as `Cow<'a, str>` again so the builder can absorb owned strings by moving them, and add: * `add_sourcemap_owned(SourceMap<'a>, u32)` / `from_owned_sourcemaps(..)` — consume owned maps and move their `Cow` entries in (no string bytes copied). * `add_sourcemap` (borrowed) and `add_sourcemap_owned` now share an `add_tokens` helper; only how the strings get in differs. `into_sourcemap` moves the accumulated vectors straight out (also cheaper than #366's rebuild for the borrowed case); `into_owned_sourcemap` keeps moved-in owned strings as-is and copies only borrowed ones. The `concat` benchmark (added in #369 as `ConcatSourceMapBuilder::from_sourcemaps`, the borrow baseline) is switched here to `ConcatSourceMapBuilder::from_owned_sourcemaps`. From the investigation sweep (200 modules): move-in is flat at ~32us regardless of `sourcesContent` size, while borrow + `into_owned_sourcemap` grows linearly (37us @256b, 47us @2KB, 70us @8kb, 542us @32kb) — up to ~16x faster, identical mappings output.
2d2f655 to
77447a4
Compare
Replace the tiny-fixture `from_sourcemaps` / `add_sourcemap_loop` concat benches (~3 KB total) with a single representative workload: a 200-module chunk, each carrying ~2 KB of `sourcesContent`, concatenated into one owned `SourceMap` — rolldown's `SourceJoiner` shape. `concat/owned_maps` measures the current `from_sourcemaps` + `into_owned_sourcemap` path.
77447a4 to
6f74fc6
Compare
#366 switched `ConcatSourceMapBuilder` to borrowed `&'a str` storage, which is optimal when inputs outlive the result. But its main consumer (rolldown's `SourceJoiner`) feeds *owned* `SourceMap<'static>` maps and wants an owned map back, so `into_owned_sourcemap` deep-copied every name/source/sourcesContent string — and `sourcesContent` is the full module text. Store entries as `Cow<'a, str>` again so the builder can absorb owned strings by moving them, and add: * `add_sourcemap_owned(SourceMap<'a>, u32)` / `from_owned_sourcemaps(..)` — consume owned maps and move their `Cow` entries in (no string bytes copied). * `add_sourcemap` (borrowed) and `add_sourcemap_owned` now share an `add_tokens` helper; only how the strings get in differs. `into_sourcemap` moves the accumulated vectors straight out (also cheaper than #366's rebuild for the borrowed case); `into_owned_sourcemap` keeps moved-in owned strings as-is and copies only borrowed ones. The `concat` benchmark group covers all four entry points: `from_sourcemaps` / `add_sourcemap` (borrow — the baseline added in #369) plus `from_owned_sourcemaps` / `add_sourcemap_owned` (the move-in variants added here). From the investigation sweep (200 modules): move-in is flat at ~32us regardless of `sourcesContent` size, while borrow + `into_owned_sourcemap` grows linearly (37us @256b, 47us @2KB, 70us @8kb, 542us @32kb) — up to ~16x faster, identical mappings output.
Replaces the tiny-fixture concat benches (
from_sourcemaps/add_sourcemap_loopover the ~3 KB on-disk fixtures) with a single representative workload that reflects how the builder is actually used: a 200-module chunk, each module carrying ~2 KB ofsourcesContent, concatenated into one ownedSourceMap— rolldown'sSourceJoinershape.concat/owned_mapsmeasures the currentfrom_sourcemaps(..).into_owned_sourcemap()path (~47 µs here). Landing it onmainfirst gives a stable baseline for follow-up concat optimizations to measure against.