mirror of
https://github.com/oxc-project/oxc.git
synced 2026-09-14 19:36:11 +08:00
overlookmotel
07a07933c7
Continuation of #26108. Previously we built the whole output as a single rope, and then flattened it in one go at the end. This is fine for smaller files, but for larger files it has 2 problems: 1. Each `output += segment` append allocates a 32-byte cons string cell. When printing a large AST, so many of these are allocated that they can fill "new space" and trigger garbage collection. When that happens, all these little cons strings have to be copied into the other half of new space, which is slow. Even worse, if they survive 2 rounds of GC, they get promoted into "old space" where (a) they may get scattered across memory, ruining cache coherence, and (b) they sit there, taking up memory, until the next major GC round. 2. Flattening a rope string which contains any segments which are 2-byte strings (non-Latin1 characters) is way more expensive than flattening a rope which is pure Latin1/ASCII. If a single segment contains Unicode, the entire flatten operation deopts and becomes several times slower. This PR attacks both these problems by flattening a large output in chunks. - When output reaches 16 KiB, flatten that as a chunk and store it in an array. - This leaves all the little cons string cells unreferenced, so garbage collection will discard them all, instead of copying them across to keep them alive. - If file contains some non-Latin1 characters, that does still heavily impact the performance of flattening the chunk they're in, but only that chunk - other chunks which are pure ASCII still take the fast path. The 16 KiB limit is a heuristic, chosen after experimentation with different values. ### Benchmarks The effect of this change is minimal on small files, but dramatic on large ones (negative is faster): | Fixture | Bytes | Change | |:---| ---:| ---:| | `tiny.js` | 26 | \+3.2% | | `RadixUIAdoptionSection.jsx` | 2,424 | \-0.1% | | `react.development.js` | 50,496 | \+2.0% | | `binder.ts` | 126,212 | \-1.9% | | `lodash.js` | 182,262 | \-32.5% | | `App.tsx` | 298,130 | \-26.4% | | `kitchen-sink.tsx` | 662,560 | \-14.2% | | `antd.js` | 5,100,647 | \-28.4% | ### Total cost of flattening After this PR, compared to where we were prior to #26106 (positive is slower): | Fixture | Bytes | Change | |:---| ---:| ---:| | `tiny.js` | 26 | \+51.5% | | `RadixUIAdoptionSection.jsx` | 2,424 | \+134.2% | | `react.development.js` | 50,496 | \+35.5% | | `binder.ts` | 126,212 | \+39.0% | | `lodash.js` | 182,262 | \+45.3% | | `App.tsx` | 298,130 | \+55.0% | | `kitchen-sink.tsx` | 662,560 | \+51.3% | | `antd.js` | 5,100,647 | \+2.2% | The effect of flattening is still very negative, but (as mentioned in #26106) it was always a cost, just one that we were ignoring. At least we've now managed to mitigate it. In the case of really large files (`antd.js`), benchmark is pretty much unchanged from before flattening came into the picture. But now our measure _includes_ the large flattening cost which was previously _on top of_ the cost of printing - so the real cost for the user is much reduced from where it was previously. ### Sourcemap builds Printing with sourcemaps on large files actually gets faster after this change. It was already paying the cost of string flattening, now it pays less. Printing `lodash.js` with sourcemaps is about 15% faster now.
60 lines
2.2 KiB
TypeScript
60 lines
2.2 KiB
TypeScript
// Indentation.
|
|
//
|
|
// One level's worth of indentation is a string, and the strings for each level are cached,
|
|
// since the same handful of levels are printed over and over.
|
|
//
|
|
// The cache is not this build's. It is created once per process alongside `State`, which carries it here,
|
|
// so the levels one build has grown are there for the next one - see `state.ts`.
|
|
|
|
import { CAT_OTHER } from "./categories.ts";
|
|
import { OUTPUT_CHUNK_LENGTH, spillOutputChunk } from "./flatten.ts";
|
|
import { write } from "./write.ts";
|
|
|
|
import type { State } from "../state.ts";
|
|
|
|
/**
|
|
* Write the indentation for the current level, or the pending single space in place of it.
|
|
*
|
|
* Inline statement bodies ask for a space where an indent would go, which keeps `if (x) foo()` on one line.
|
|
*/
|
|
export function printIndent(state: State): void {
|
|
// Flatten chunk if `state.output` has grown beyond limit.
|
|
// Once per line, not once per write - see comment on `OUTPUT_CHUNK_LENGTH` in `flatten.ts`.
|
|
if (state.output.length >= OUTPUT_CHUNK_LENGTH) spillOutputChunk(state);
|
|
|
|
if (state.pendingIndentAsSpace) {
|
|
write(state, " ", CAT_OTHER);
|
|
state.pendingIndentAsSpace = false;
|
|
return;
|
|
}
|
|
|
|
const level = state.indentLevel;
|
|
if (level > 0) {
|
|
// Indentation is validated to contain only spaces and tabs, neither of which any reader
|
|
// of `last` distinguishes, so the category is a constant
|
|
const { indents } = state;
|
|
write(state, level < indents.length ? indents[level] : growIndents(state, level), CAT_OTHER);
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Extend the indent cache up to `level` and return the indent for it.
|
|
*
|
|
* Separate from `printIndent` so the cached lookup there stays small enough to inline.
|
|
*/
|
|
function growIndents(state: State, level: number): string {
|
|
const { indents, indentString } = state;
|
|
|
|
let { length } = indents;
|
|
let indent = indents[length - 1];
|
|
for (; length <= level; length++) {
|
|
// Use `join` instead of `indent += indentString` to produce a flat string instead of a rope.
|
|
// That costs a little here, but is a one-time cost, and it is appended to the output many times afterwards,
|
|
// so reduces the number of segments in `output` rope string for every file.
|
|
indent = [indent, indentString].join("");
|
|
indents.push(indent);
|
|
}
|
|
|
|
return indent;
|
|
}
|