perf: use @jridgewell/sourcemap-codec

[sapphi-red]

@jridgewell/sourcemap-codec has better performance and memory footprint than sourcemap-codec.

This PR replaces sourcemap-codec with @jridgewell/sourcemap-codec.

before

node v16.16.0

generateMap (no edit) x 1,664 ops/sec ±0.62% (92 runs sampled)
generateMap (edit) x 1,651 ops/sec ±0.74% (92 runs sampled)

after

node v16.16.0

generateMap (no edit) x 1,981 ops/sec ±0.52% (93 runs sampled)
generateMap (edit) x 1,901 ops/sec ±0.56% (93 runs sampled)

[sapphi-red]

node12 supports up to ES2019. But ES2020 is needed to parse import.meta.url.

[aleclarson]

Looks good to me 👍

For context, @jridgewell is the author of @ampproject/remapping (the best-in-class sourcemap chain flattener), so I trust in this fork's quality of maintenance.

[sapphi-red]

@aleclarson FYI this pull request is waiting to see what happens with #216 (comment).

[jdalton]

@jridgewell it looks like @jridgewell/sourcemap-codec is a fork of Rich's. Do you have a summary of changed done to it?

To others: Should the original sourcemap-codec be deprecated?

[jridgewell]

You're only using the encode methods, so the relevant change is the use of a TextDecoder (or Buffer if your node version is old) to convert from the base64 bytes into a the string.

Sourcemaps are essentially a Line[], where each Line is a Segment[], and each Segment is a tuple of ints. Rich's implementations allocates an array per line, encodes each segment into a base64 string (using small concatenations, which is too small for v8's rope concatenations to kick in), and pushes the encoding into the line (array expansion costs). It then joins the array together, and pushes that onto the overall mappings string (this uses rope optimizations once the mappings is large enough).

My implementation uses a 16kb Uint8Array buffer. The individual base64 char is placed into the buffer, and when it fills I use a TextDecoder to covert them into a string in one shot. I then start filling the buffer again. This avoids small string concatenations, array expansions, and guarantees the rope optimizations kick in immediately (because 16kb is large enough).

[Rich-Harris]

To others: Should the original sourcemap-codec be deprecated?

Yes, I think it should (sorry, dropped the ball on this whole convo, doing some inbox spring-cleaning). The fork has more downloads than the original, and I would wager the vast majority of sourcemap-codec's downloads are via magic-string, so deprecating it in favour of @jridgewell/sourcemap-codec would be the least disruptive move. Thanks @jridgewell for taking the initiative, I appreciate it 🍻

[Rich-Harris]

Released 0.27 with this change