Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert the codebase to modules #51387

Merged
merged 36 commits into from
Nov 7, 2022
Merged

Conversation

jakebailey
Copy link
Member

@jakebailey jakebailey commented Nov 2, 2022

This is it; the PR that converts the TypeScript repo from namespaces to modules.

TL;DR: The TypeScript compiler is now implemented internally with modules, not namespaces. The compiler is now 10-25% faster. tsc is now 30% faster to start. Our npm package is now 43% smaller. More improvements are in the works.

If you're reading this and the 5.0 beta is out, now that the above results were as of this PR; the final performance change of TS 5.0 is different!

Closes #35210
Closes #39247
Closes #49037
Closes #49332
Closes #50758
For #27891
For #32949
For #34617

For those who are looking at the diff and wondering how they can see what this PR actually does, consider looking at each commit, or look at my silly stacked PR gerrit-clone thing at jakebailey#1 (which I will try to keep up to date).

Want to try this out now? Set this in your package.json:

"typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-51387-49"

(Or, wait until the next nightly after this is merged.)

How?

The bulk of the work to convert the repo to modules is done via automation, followed by a load of changes by hand to completely restructure our build system. To see the conversion process, take a look at the commits in this PR, each of which come with their own descriptive commit message.

In short, the typeformer project recreates our old namespaces as "barrel" modules, reexporting each file from the barrel module corresponding to its original namespace. Symbols which previously were available "globally" via namespaces are now imported in big import blocks at the top of each file, in such a way that the final code looks nearly identical to the input (but unindented one level).

This, with a little hand modification, gets us to a place where we can emit CJS and have everything working.

However, this turns out to incur a big performance penalty; our old TS namespaces were just objects, but CJS imports/exports are more expensive than plain objects. Additionally, many consumers currently expect to be able to load TS as a single file, and that same file must be usable in Node and the browser. Unless we wanted to change that expectation and break the world, we needed to bundle.

As an experiment while working on this conversion, I tried simply running esbuild on our source files directly; with a little more tweaking, I was able to produce a working output for our codebase. Unexpectedly, this also brought major performance wins in our benchmarks (see the next section). Those performance benefits (and speedy build times) were too good to pass up, and so, our main JS outputs are now produced by esbuild.

To mitigate the risk of not using tsc's output, I have created a --bundle=false mode for our build. This mode uses tsc to emit CJS, producing modules matching src 1:1. This is tested in CI so we can reliably switch back to tsc's CJS emit if needed. The new build is also constructed such that it'd be easy to transition to running a bundler on tsc's ESM emit (rather than directly on src).

Since our outputs are bundled, we needed a way to "bundle" our d.ts files too. To handle this, I wrote a small-ish (400 line) d.ts bundler that can serve our needs. This bundler is "dumb" and cannot handle cases that a more widely-usable bundler (like api-extractor) should, e.g. properly renaming types with the same name but declared in separate files or avoiding aliasing globals, which are cases that we can avoid or ignore, respectively.

Benefits for users of TypeScript

Firstly, the performance of the compiler has increased by anywhere from 10 to 25%. This largely thanks to scope lifting. TypeScript namespaces are emitted as a series of IIFEs which push properties onto a single object. Non-local accesses to exports of that namespace are implicitly fully qualified, incurring the overhead of an object access. With modules, all of our internal helpers have been lifted to the top and are available for direct calls.

Secondly, our package is now ~43% smaller (from 63.6 MB down to 35.6 MB). This is due in part to dropping some redundant files from our package, including typescriptServices.js, which was identical to typescript.js (see the breaking changes section below), a change in the indentation used in our bundle files (4 spaces -> 2 spaces), plus a large amount of tree shaking in tsc.js and typingsInstaller.js. TypeScript 4.9 was made smaller by 2 MB already (thanks to #50421), so this is excellent progress.

Finally, as a result of both of the previous performance improvements (faster code and less of it), tsc.js is 30% faster to start and typescript.js (our public API) is 10% faster to import. As we improve performance and code size, these numbers are likely to improve. We now include these metrics in our benchmarks to track over time and in relevant PRs.

Benefits for the TypeScript team (and contributors)

For those who work on TypeScript itself, this change comes with a number of important benefits.

Now that we are modules, we are dogfooding the module experience. Effectively everyone is using modules and has been for a long time, but we've been using namespaces. This left us unable to experience things like auto-imports, giant import blocks, etc, ourselves. (During testing of this PR, we found multiple interesting auto-import and quick fix bugs; win!)

Being modules also provides us the ability to start integrating excellent external tooling into our build process. As previously mentioned, our JS outputs are now produced by esbuild. This lets us start running tests in seconds (or less), representing a significant shortening of the develop/test/debug loop.1 Of course, this is potentially limiting; if we need new syntax features that aren't yet implemented in esbuild, we can switch to bundling the ESM output of tsc instead, restoring the status quo.

Additionally, since I had to change the entire build process to support this conversion, it's a great time to make build changes that would normally be difficult during our typical dev cycle. This includes replacing our task runner with a lightweight alternative (we don't need too much fanciness anymore), rewriting/deleting a number of scripts, and removing/replacing outdated dependencies. After this change, our npm audit is clean and our dev dependency count has been halved.

No, we're not yet shipping ESM

This PR does not convert the TypeScript package to ESM (#32949). The package still consists of a handful of un-tree-shakeable large files (though there are now fewer of them, and they are smaller). Allowing TypeScript to be packaged as ESM is a further challenge that will build on this change, but for this PR, the goal is to convert the repo's source files to modules without causing major breaks for downstream users. (For the future, see the "future" section below.)

Breaking changes

This conversion introduces a number of breaking changes for consumers of the TypeScript package; those using tsc or the language service in their editor should see no changes (besides improved performance and smaller install sizes).

  • typescriptServices.js has been removed; this file was identical to typescript.js, the entrypoint for our npm package.
  • protocol.d.ts is no longer included in the package; use tsserverlibrary.d.ts's ts.server.protocol namespace instead.
    • Some elements of the protocol are not actually exported by the ts.server.protocol namespace, but were emitted in the old protocol.d.ts file, and may need to be accessed off of the ts namespace instead. See Don't depend on typescript protocol.d.ts vscode#163365 for an potential way to minimize changes to protocol-using codebases.
  • The output files have changed significantly; if you are patching TypeScript, you will definitely need to change your patches.
    • Since I know prettier post-processes our package to extract just enough of the codebase to parse code, I have created a proof-of-concept that can be expanded on to achieve a similar result with the new 5.0 output by using a tool like terser or rollup to tree-shake inside of the library itself. In the future, we may be able to improve this situation by restructuring our codebase in a way that allows us to export just the parser (Create a parser npm module #34617). cc @fisker
  • The TypeScript package now targets ES2018. Prior to 5.0, our package targeted ES5 syntax and the ES2015 library, however, esbuild has a hard minimum syntax target of ES2015 (aka ES6). ES2018 was chosen as a balance between compatibility with older environments and access to more modern syntax and library features.2
    • If you are looking to run the TypeScript compiler itself in an environment older than ES2018, you will need to downlevel our package's syntax and potentially polyfill the environment. (This may have already been the case; we don't test the TypeScript compiler on EOL versions of Node in CI and we're aware of a handful of cases where we were already using helpers outside our target range unconditionally.)

The future?

The module conversion opens the door to many future improvements.

Our codebase is massively circular thanks to how easy it was to introduce cycles with namespaces. Namespace emit ordering was controlled by tsconfig.json, which allowed us to structure things "just right" and not crash, but things aren't so straightforward in modules. The modules themselves define their execution order, and the current state is one that works (even if the use of "namespace barrels" is suboptimal). But, this shouldn't be permanent; now that we are modules and it's not costly to introduce new files into the mix, we can start restructuring the codebase and unraveling our import cycles. In an ESM future, breaking these cycles may lead to improved tree shaking for those who bundle TypeScript into their codebases.

In terms of performance, a small number of namespaces remain in the codebase (Debug, Parser, others) which would benefit from being converted to modules to allow for direct calls. We also lost some performance in our parser due to let/const (disproportionally so; the other parts of the compiler were only slightly affected but had much larger net wins). We may be able to restructure the parser to avoid the temporal dead zone performance cost.3

In terms of code size, may even be able to do some amount of ESM emit now. A few of our bundles are not for import, only for execution (tsc, tsserver, typingsInstaller). If we are willing to drop versions of Node before ESM (Node <12), we can drop another 7 MB from our package by using esbuild's ESM code splitting for those bundles.

In the process of making bundling work, I fixed monaco to no longer depend on the source-level structure of our package. This means that we could potentially start minifying our codebase, reducing the package size significantly. This is not without gotchas, of course; we know that there are downstream users who patch our package post-install, which is much more difficult when the output isn't predictably formatted (or effectively impossible using "patch" when minified).

On the shoulders of giants

I have many people to thank:

  • @weswigham and @elibarzilay, who authored the previous versions of the typeformer project. They did most of the hard work in conceptualizing how this could be possible and providing a base set of transforms to get it done.
  • @dsherret, for the excellent ts-morph, with which I rewrote the typeformer project for excellent TS-to-TS source modification fidelity.
  • @evanw, for the excellent esbuild, which gives us speedy build times and an output that is faster for our users.
  • Everyone on the team who tested this PR out early and helped iron out the bugs. This PR touches effectively every line of code in the project; testing is key!

PR notes:

  • This PR MUST be merged via a merge commit. Squashing will break .git-blame-ignore-revs as it references specific commits in the PR that git blame should ignore; I want to ignore only the automated steps in this PR. I have attempted to make this PR as few commits as possible while still making sense.
  • The breaking changes listed above need to be added to the wiki (without all of my exposition).
  • Until the point at which we are ready to merge this, expect this PR to either have conflicts. The nature of this transformation means that any change to src in main will cause this PR to have conflicts, and the only way to fix that is to rerun the entire transformation from scratch and force push.

Footnotes

  1. Specifically, the time it takes to to run the "local" build task (everything but tests) has been reduced from ~30s to ~20s on my machine. When changing the checker, the build time has been reduced from ~18s to ~14 seconds. When changing nothing, the build time has been reduced from 1.3s to 0.7s.

  2. ES2018 is the ECMAScript version implemented by Node 10. We could have bumped to ES2019 (Node 12), but this would only give us optional catch binding; we already conditionally use newer library features like trimStart / trimEnd. We could have also bumped up to ES2020 (Node 14, though, see Recommended tsconfig.json target option for Node 14 is ES2020 which is not fully supported by Node 14. #46325), which would give us native nullish coalescing and optional chaining, but it seemed like too big of a jump to drop Node 12, even if it is end-of-life and untested in our CI.

  3. In an earlier revision of this stack, I used babel to downlevel let/const to var after bundling. This increased performance as expected, but we decided to not add this step; in the ESM future, we wouldn't want to end up with all of our export const declarations turning into export var, and avoiding the transformation simplifies the build and improves the debugging experience when loops are involved. If we change our minds, this is easy to reimplement, albeit slow.

@typescript-bot
Copy link
Collaborator

Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary

@typescript-bot typescript-bot added the For Milestone Bug PRs that fix a bug with a specific milestone label Nov 2, 2022
@jakebailey
Copy link
Member Author

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this
@typescript-bot pack this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the diff-based top-repos suite (tsserver) on this PR at 4ddaab5. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the tarball bundle task on this PR at 4ddaab5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the extended test suite on this PR at 4ddaab5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 4ddaab5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 4ddaab5. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the perf test suite on this PR at 4ddaab5. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 4ddaab5. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Heya @jakebailey, I've started to run the diff-based user code test suite (tsserver) on this PR at 4ddaab5. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 2, 2022

Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/137480/artifacts?artifactName=tgz&fileId=08B819ABB40DEE8CC5C34203005549FD20C0C0D9489D7C8D01E9D8A9C76FF4C102&fileName=/typescript-5.0.0-insiders.20221102.tgz"
    }
}

and then running npm install.


There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.0.0-pr-51387-10".;

@typescript-bot
Copy link
Collaborator

@jakebailey Here are the results of running the user test suite comparing main and refs/pull/51387/merge:

Everything looks good!

1 similar comment
@typescript-bot
Copy link
Collaborator

@jakebailey Here are the results of running the user test suite comparing main and refs/pull/51387/merge:

Everything looks good!

@zachkirsch
Copy link

Wahoo!!

@jakebailey jakebailey added Breaking Change Would introduce errors in existing code API Relates to the public API for TypeScript and removed Breaking Change Would introduce errors in existing code labels Nov 2, 2022
@typescript-bot
Copy link
Collaborator

@jakebailey
The results of the perf run you requested are in!

Here they are:

Compiler

Comparison Report - main..51387
Metric main 51387 Delta Best Worst
Angular - node (v18.10.0, x64)
Memory used 353,963k (± 0.02%) 341,189k (± 0.02%) 🟩-12,774k (- 3.61%) 340,973k 341,325k
Parse Time 1.56s (± 0.49%) 1.56s (± 1.07%) +0.01s (+ 0.51%) 1.53s 1.61s
Bind Time 0.61s (± 0.60%) 0.53s (± 1.09%) 🟩-0.07s (-12.05%) 0.52s 0.54s
Check Time 4.42s (± 0.55%) 4.04s (± 0.81%) 🟩-0.38s (- 8.71%) 3.97s 4.13s
Emit Time 4.93s (± 0.64%) 4.24s (± 0.68%) 🟩-0.68s (-13.86%) 4.16s 4.28s
Total Time 11.51s (± 0.46%) 10.38s (± 0.54%) 🟩-1.13s (- 9.83%) 10.22s 10.48s
Compiler-Unions - node (v18.10.0, x64)
Memory used 200,772k (± 0.62%) 189,497k (± 0.65%) 🟩-11,275k (- 5.62%) 184,501k 190,132k
Parse Time 0.60s (± 1.33%) 0.62s (± 0.76%) +0.02s (+ 3.49%) 0.61s 0.63s
Bind Time 0.36s (± 0.94%) 0.33s (± 1.04%) 🟩-0.04s (- 9.92%) 0.32s 0.33s
Check Time 5.37s (± 0.75%) 4.97s (± 0.80%) 🟩-0.40s (- 7.41%) 4.88s 5.07s
Emit Time 1.81s (± 0.81%) 1.53s (± 0.96%) 🟩-0.28s (-15.57%) 1.50s 1.57s
Total Time 8.15s (± 0.71%) 7.46s (± 0.63%) 🟩-0.70s (- 8.54%) 7.35s 7.59s
Monaco - node (v18.10.0, x64)
Memory used 331,748k (± 0.01%) 320,323k (± 0.01%) 🟩-11,425k (- 3.44%) 320,228k 320,396k
Parse Time 1.17s (± 0.65%) 1.16s (± 1.01%) -0.01s (- 0.94%) 1.13s 1.18s
Bind Time 0.56s (± 1.25%) 0.49s (± 0.98%) 🟩-0.07s (-13.19%) 0.48s 0.50s
Check Time 4.31s (± 0.90%) 3.87s (± 0.64%) 🟩-0.44s (-10.31%) 3.81s 3.93s
Emit Time 2.61s (± 0.72%) 2.24s (± 0.82%) 🟩-0.38s (-14.43%) 2.21s 2.28s
Total Time 8.66s (± 0.71%) 7.75s (± 0.57%) 🟩-0.91s (-10.52%) 7.67s 7.86s
TFS - node (v18.10.0, x64)
Memory used 294,811k (± 0.01%) 283,086k (± 0.15%) 🟩-11,725k (- 3.98%) 282,571k 284,787k
Parse Time 0.94s (± 1.05%) 0.96s (± 1.28%) +0.02s (+ 2.56%) 0.93s 1.00s
Bind Time 0.60s (± 3.95%) 0.45s (± 5.92%) 🟩-0.15s (-25.67%) 0.42s 0.55s
Check Time 4.01s (± 0.67%) 3.79s (± 0.63%) 🟩-0.22s (- 5.49%) 3.72s 3.83s
Emit Time 2.63s (± 0.60%) 2.18s (± 0.76%) 🟩-0.45s (-17.25%) 2.15s 2.21s
Total Time 8.18s (± 0.72%) 7.38s (± 0.40%) 🟩-0.81s (- 9.86%) 7.32s 7.45s
material-ui - node (v18.10.0, x64)
Memory used 439,901k (± 0.01%) 428,116k (± 0.02%) -11,785k (- 2.68%) 428,021k 428,314k
Parse Time 1.37s (± 0.84%) 1.34s (± 1.05%) -0.02s (- 1.68%) 1.32s 1.38s
Bind Time 0.44s (± 1.07%) 0.49s (± 1.00%) +0.05s (+12.27%) 0.48s 0.50s
Check Time 10.83s (± 0.24%) 10.07s (± 0.71%) 🟩-0.76s (- 7.04%) 9.91s 10.22s
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) 0.00s ( NaN%) 0.00s 0.00s
Total Time 12.64s (± 0.22%) 11.91s (± 0.62%) 🟩-0.73s (- 5.80%) 11.75s 12.07s
xstate - node (v18.10.0, x64)
Memory used 557,292k (± 0.01%) 518,650k (± 0.01%) 🟩-38,642k (- 6.93%) 518,577k 518,712k
Parse Time 1.91s (± 0.56%) 1.91s (± 0.64%) 0.00s ( 0.00%) 1.89s 1.94s
Bind Time 0.69s (± 2.31%) 0.78s (± 2.75%) +0.09s (+12.46%) 0.73s 0.82s
Check Time 1.10s (± 0.62%) 1.04s (± 0.96%) 🟩-0.06s (- 5.52%) 1.01s 1.06s
Emit Time 0.06s (± 0.00%) 0.06s (± 5.97%) 🟩-0.00s (- 5.00%) 0.05s 0.06s
Total Time 3.76s (± 0.52%) 3.78s (± 0.64%) +0.03s (+ 0.67%) 3.73s 3.84s
Angular - node (v16.17.1, x64)
Memory used 353,451k (± 0.02%) 340,567k (± 0.02%) 🟩-12,885k (- 3.65%) 340,356k 340,667k
Parse Time 1.90s (± 0.53%) 1.87s (± 0.47%) -0.03s (- 1.58%) 1.85s 1.90s
Bind Time 0.75s (± 0.89%) 0.64s (± 0.76%) 🟩-0.11s (-14.13%) 0.64s 0.66s
Check Time 5.70s (± 0.46%) 5.11s (± 0.55%) 🟩-0.59s (-10.36%) 5.05s 5.17s
Emit Time 6.10s (± 0.47%) 5.06s (± 0.67%) 🟩-1.04s (-17.11%) 4.96s 5.12s
Total Time 14.46s (± 0.39%) 12.69s (± 0.34%) 🟩-1.77s (-12.22%) 12.59s 12.77s
Compiler-Unions - node (v16.17.1, x64)
Memory used 198,088k (± 0.49%) 188,067k (± 0.65%) 🟩-10,021k (- 5.06%) 185,981k 189,586k
Parse Time 0.79s (± 1.22%) 0.79s (± 0.43%) +0.00s (+ 0.25%) 0.78s 0.79s
Bind Time 0.45s (± 0.89%) 0.42s (± 0.89%) 🟩-0.04s (- 7.98%) 0.41s 0.42s
Check Time 6.43s (± 0.56%) 5.93s (± 0.52%) 🟩-0.50s (- 7.75%) 5.87s 5.99s
Emit Time 2.26s (± 0.85%) 1.90s (± 1.02%) 🟩-0.36s (-16.05%) 1.86s 1.94s
Total Time 9.92s (± 0.34%) 9.03s (± 0.50%) 🟩-0.89s (- 9.01%) 8.96s 9.13s
Monaco - node (v16.17.1, x64)
Memory used 331,211k (± 0.02%) 319,611k (± 0.01%) 🟩-11,600k (- 3.50%) 319,554k 319,651k
Parse Time 1.43s (± 0.62%) 1.43s (± 0.71%) -0.01s (- 0.63%) 1.41s 1.44s
Bind Time 0.69s (± 0.84%) 0.59s (± 0.50%) 🟩-0.10s (-14.57%) 0.59s 0.60s
Check Time 5.47s (± 0.58%) 4.85s (± 0.50%) 🟩-0.62s (-11.35%) 4.82s 4.90s
Emit Time 3.25s (± 0.50%) 2.69s (± 0.63%) 🟩-0.56s (-17.28%) 2.65s 2.72s
Total Time 10.85s (± 0.36%) 9.56s (± 0.34%) 🟩-1.29s (-11.91%) 9.52s 9.66s
TFS - node (v16.17.1, x64)
Memory used 294,130k (± 0.02%) 282,238k (± 0.01%) 🟩-11,892k (- 4.04%) 282,172k 282,258k
Parse Time 1.23s (± 0.89%) 1.16s (± 0.71%) 🟩-0.06s (- 5.21%) 1.14s 1.18s
Bind Time 0.64s (± 1.37%) 0.67s (± 3.75%) +0.03s (+ 4.35%) 0.58s 0.72s
Check Time 5.14s (± 0.45%) 4.74s (± 0.56%) 🟩-0.40s (- 7.86%) 4.69s 4.81s
Emit Time 3.49s (± 0.40%) 2.74s (± 2.18%) 🟩-0.75s (-21.50%) 2.65s 2.86s
Total Time 10.50s (± 0.39%) 9.31s (± 1.04%) 🟩-1.19s (-11.37%) 9.16s 9.51s
material-ui - node (v16.17.1, x64)
Memory used 439,323k (± 0.02%) 427,401k (± 0.00%) -11,923k (- 2.71%) 427,380k 427,411k
Parse Time 1.72s (± 1.19%) 1.64s (± 0.81%) 🟩-0.08s (- 4.88%) 1.62s 1.67s
Bind Time 0.54s (± 0.63%) 0.50s (± 1.33%) 🟩-0.04s (- 6.89%) 0.49s 0.52s
Check Time 12.44s (± 0.57%) 11.58s (± 0.62%) 🟩-0.87s (- 6.95%) 11.47s 11.77s
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) 0.00s ( NaN%) 0.00s 0.00s
Total Time 14.70s (± 0.46%) 13.72s (± 0.57%) 🟩-0.98s (- 6.69%) 13.63s 13.92s
xstate - node (v16.17.1, x64)
Memory used 554,924k (± 0.01%) 516,288k (± 0.01%) 🟩-38,636k (- 6.96%) 516,155k 516,473k
Parse Time 2.31s (± 0.35%) 2.31s (± 0.46%) -0.00s (- 0.22%) 2.28s 2.33s
Bind Time 0.89s (± 2.01%) 0.84s (± 1.77%) 🟩-0.05s (- 5.17%) 0.81s 0.89s
Check Time 1.43s (± 0.80%) 1.35s (± 0.52%) 🟩-0.08s (- 5.86%) 1.33s 1.36s
Emit Time 0.07s (± 4.37%) 0.06s (± 0.00%) 🟩-0.01s (-11.76%) 0.06s 0.06s
Total Time 4.70s (± 0.39%) 4.57s (± 0.35%) -0.14s (- 2.89%) 4.53s 4.59s
Angular - node (v14.15.1, x64)
Memory used 347,641k (± 0.01%) 334,066k (± 0.01%) 🟩-13,575k (- 3.91%) 334,031k 334,115k
Parse Time 2.07s (± 0.45%) 2.06s (± 0.51%) -0.02s (- 0.77%) 2.03s 2.08s
Bind Time 0.80s (± 0.87%) 0.70s (± 1.06%) 🟩-0.10s (-12.61%) 0.68s 0.71s
Check Time 6.00s (± 0.40%) 5.52s (± 0.70%) 🟩-0.48s (- 8.03%) 5.45s 5.60s
Emit Time 6.29s (± 0.94%) 5.26s (± 1.14%) 🟩-1.03s (-16.34%) 5.14s 5.37s
Total Time 15.16s (± 0.43%) 13.54s (± 0.74%) 🟩-1.62s (-10.71%) 13.33s 13.73s
Compiler-Unions - node (v14.15.1, x64)
Memory used 190,940k (± 0.67%) 182,029k (± 0.65%) 🟩-8,911k (- 4.67%) 180,480k 184,472k
Parse Time 0.86s (± 0.47%) 0.90s (± 0.49%) +0.04s (+ 5.01%) 0.89s 0.91s
Bind Time 0.49s (± 1.06%) 0.46s (± 0.48%) 🟩-0.03s (- 6.11%) 0.46s 0.47s
Check Time 6.78s (± 0.55%) 6.29s (± 0.63%) 🟩-0.48s (- 7.13%) 6.17s 6.35s
Emit Time 2.43s (± 0.88%) 2.06s (± 1.60%) 🟩-0.37s (-15.35%) 2.02s 2.17s
Total Time 10.56s (± 0.39%) 9.71s (± 0.40%) 🟩-0.84s (- 7.98%) 9.63s 9.82s
Monaco - node (v14.15.1, x64)
Memory used 326,563k (± 0.01%) 314,468k (± 0.02%) 🟩-12,095k (- 3.70%) 314,372k 314,561k
Parse Time 1.59s (± 0.75%) 1.59s (± 0.63%) -0.00s (- 0.06%) 1.57s 1.61s
Bind Time 0.73s (± 0.41%) 0.64s (± 1.10%) 🟩-0.09s (-12.70%) 0.63s 0.66s
Check Time 5.76s (± 0.39%) 5.21s (± 0.25%) 🟩-0.55s (- 9.58%) 5.18s 5.25s
Emit Time 3.39s (± 0.38%) 2.88s (± 0.80%) 🟩-0.50s (-14.86%) 2.85s 2.94s
Total Time 11.47s (± 0.18%) 10.32s (± 0.35%) 🟩-1.15s (-10.03%) 10.27s 10.44s
TFS - node (v14.15.1, x64)
Memory used 289,789k (± 0.01%) 279,265k (± 0.01%) 🟩-10,525k (- 3.63%) 279,185k 279,325k
Parse Time 1.29s (± 0.48%) 1.35s (± 1.37%) +0.06s (+ 4.50%) 1.31s 1.39s
Bind Time 0.80s (± 0.45%) 0.59s (± 0.80%) 🟩-0.21s (-26.24%) 0.58s 0.60s
Check Time 5.40s (± 0.35%) 5.10s (± 0.40%) 🟩-0.30s (- 5.52%) 5.08s 5.17s
Emit Time 3.61s (± 0.84%) 3.06s (± 0.89%) 🟩-0.55s (-15.20%) 2.99s 3.12s
Total Time 11.11s (± 0.33%) 10.11s (± 0.32%) 🟩-1.00s (- 9.04%) 10.03s 10.17s
material-ui - node (v14.15.1, x64)
Memory used 435,469k (± 0.00%) 422,806k (± 0.01%) -12,663k (- 2.91%) 422,708k 422,860k
Parse Time 1.90s (± 0.92%) 1.89s (± 0.49%) -0.01s (- 0.53%) 1.88s 1.92s
Bind Time 0.59s (± 0.62%) 0.54s (± 0.96%) 🟩-0.05s (- 8.02%) 0.53s 0.55s
Check Time 12.87s (± 0.38%) 12.09s (± 0.64%) 🟩-0.79s (- 6.10%) 11.94s 12.24s
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) 0.00s ( NaN%) 0.00s 0.00s
Total Time 15.36s (± 0.35%) 14.52s (± 0.55%) 🟩-0.84s (- 5.49%) 14.36s 14.69s
xstate - node (v14.15.1, x64)
Memory used 543,999k (± 0.01%) 504,396k (± 0.01%) 🟩-39,603k (- 7.28%) 504,336k 504,458k
Parse Time 2.61s (± 0.59%) 2.64s (± 0.77%) +0.03s (+ 1.11%) 2.60s 2.69s
Bind Time 0.98s (± 1.17%) 0.85s (± 0.76%) 🟩-0.13s (-13.33%) 0.84s 0.87s
Check Time 1.51s (± 0.39%) 1.48s (± 0.40%) -0.03s (- 1.98%) 1.47s 1.49s
Emit Time 0.07s (± 3.14%) 0.07s (± 0.00%) -0.00s (- 1.41%) 0.07s 0.07s
Total Time 5.18s (± 0.35%) 5.05s (± 0.37%) -0.13s (- 2.55%) 4.99s 5.07s
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
Available Memory15 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hosts
  • node (v18.10.0, x64)
  • node (v16.17.1, x64)
  • node (v14.15.1, x64)
Scenarios
  • Angular - node (v18.10.0, x64)
  • Angular - node (v16.17.1, x64)
  • Angular - node (v14.15.1, x64)
  • Compiler-Unions - node (v18.10.0, x64)
  • Compiler-Unions - node (v16.17.1, x64)
  • Compiler-Unions - node (v14.15.1, x64)
  • Monaco - node (v18.10.0, x64)
  • Monaco - node (v16.17.1, x64)
  • Monaco - node (v14.15.1, x64)
  • TFS - node (v18.10.0, x64)
  • TFS - node (v16.17.1, x64)
  • TFS - node (v14.15.1, x64)
  • material-ui - node (v18.10.0, x64)
  • material-ui - node (v16.17.1, x64)
  • material-ui - node (v14.15.1, x64)
  • xstate - node (v18.10.0, x64)
  • xstate - node (v16.17.1, x64)
  • xstate - node (v14.15.1, x64)
Benchmark Name Iterations
Current 51387 10
Baseline main 10

TSServer

Comparison Report - main..51387
Metric main 51387 Delta Best Worst
Compiler-UnionsTSServer - node (v18.10.0, x64)
Req 1 - updateOpen 1,066ms (± 0.34%) 1,058ms (± 0.73%) -9ms (- 0.83%) 1,042ms 1,081ms
Req 2 - geterr 2,738ms (± 0.48%) 2,525ms (± 0.85%) 🟩-212ms (- 7.75%) 2,488ms 2,565ms
Req 3 - references 191ms (± 0.97%) 166ms (± 0.42%) 🟩-26ms (-13.32%) 165ms 168ms
Req 4 - navto 147ms (± 1.34%) 140ms (± 2.21%) 🟩-7ms (- 4.97%) 137ms 152ms
Req 5 - completionInfo count 1,356 (± 0.00%) 1,356 (± 0.00%) 0 ( 0.00%) 1,356 1,356
Req 5 - completionInfo 44ms (± 1.27%) 61ms (± 2.32%) 🔻+17ms (+38.58%) 57ms 62ms
CompilerTSServer - node (v18.10.0, x64)
Req 1 - updateOpen 1,132ms (± 0.81%) 1,113ms (± 0.82%) -20ms (- 1.75%) 1,087ms 1,128ms
Req 2 - geterr 1,616ms (± 0.58%) 1,513ms (± 0.63%) 🟩-103ms (- 6.38%) 1,496ms 1,544ms
Req 3 - references 198ms (± 0.95%) 176ms (± 4.29%) 🟩-22ms (-11.16%) 167ms 196ms
Req 4 - navto 161ms (± 1.18%) 175ms (± 9.71%) +14ms (+ 8.83%) 149ms 200ms
Req 5 - completionInfo count 1,518 (± 0.00%) 1,518 (± 0.00%) 0 ( 0.00%) 1,518 1,518
Req 5 - completionInfo 86ms (± 6.89%) 52ms (± 4.33%) 🟩-34ms (-39.93%) 48ms 56ms
xstateTSServer - node (v18.10.0, x64)
Req 1 - updateOpen 1,628ms (± 0.43%) 1,521ms (± 0.68%) 🟩-107ms (- 6.59%) 1,497ms 1,547ms
Req 2 - geterr 570ms (± 0.63%) 556ms (± 0.85%) -14ms (- 2.44%) 545ms 569ms
Req 3 - references 52ms (± 1.28%) 59ms (± 2.22%) +7ms (+13.27%) 57ms 62ms
Req 4 - navto 207ms (± 0.85%) 196ms (± 0.64%) 🟩-11ms (- 5.08%) 193ms 198ms
Req 5 - completionInfo count 3,209 (± 0.00%) 3,149 (± 0.00%) -60 (- 1.87%) 3,149 3,149
Req 5 - completionInfo 209ms (± 1.79%) 210ms (± 1.29%) +1ms (+ 0.53%) 205ms 216ms
Compiler-UnionsTSServer - node (v16.17.1, x64)
Req 1 - updateOpen 1,329ms (± 0.37%) 1,309ms (± 0.50%) -20ms (- 1.52%) 1,293ms 1,323ms
Req 2 - geterr 3,266ms (± 0.72%) 3,071ms (± 0.53%) 🟩-196ms (- 5.99%) 3,018ms 3,097ms
Req 3 - references 224ms (± 1.19%) 195ms (± 0.89%) 🟩-30ms (-13.21%) 191ms 199ms
Req 4 - navto 158ms (± 0.61%) 157ms (± 7.29%) -1ms (- 0.63%) 149ms 203ms
Req 5 - completionInfo count 1,356 (± 0.00%) 1,356 (± 0.00%) 0 ( 0.00%) 1,356 1,356
Req 5 - completionInfo 53ms (± 1.16%) 61ms (± 6.30%) +8ms (+15.44%) 56ms 72ms
CompilerTSServer - node (v16.17.1, x64)
Req 1 - updateOpen 1,411ms (± 0.46%) 1,376ms (± 0.59%) -35ms (- 2.45%) 1,356ms 1,388ms
Req 2 - geterr 2,123ms (± 0.48%) 1,995ms (± 0.40%) 🟩-129ms (- 6.06%) 1,981ms 2,013ms
Req 3 - references 232ms (± 0.78%) 199ms (± 0.79%) 🟩-34ms (-14.43%) 195ms 202ms
Req 4 - navto 172ms (± 1.22%) 167ms (± 0.89%) -4ms (- 2.50%) 164ms 171ms
Req 5 - completionInfo count 1,518 (± 0.00%) 1,518 (± 0.00%) 0 ( 0.00%) 1,518 1,518
Req 5 - completionInfo 52ms (± 1.43%) 56ms (± 2.13%) +4ms (+ 7.65%) 55ms 59ms
xstateTSServer - node (v16.17.1, x64)
Req 1 - updateOpen 1,920ms (± 0.52%) 1,814ms (± 0.52%) 🟩-106ms (- 5.52%) 1,792ms 1,832ms
Req 2 - geterr 734ms (± 0.59%) 712ms (± 0.64%) 🟩-22ms (- 3.02%) 702ms 720ms
Req 3 - references 60ms (± 1.25%) 67ms (± 1.26%) +7ms (+11.09%) 66ms 69ms
Req 4 - navto 209ms (± 0.81%) 198ms (± 0.94%) 🟩-11ms (- 5.37%) 194ms 202ms
Req 5 - completionInfo count 3,209 (± 0.00%) 3,149 (± 0.00%) -60 (- 1.87%) 3,149 3,149
Req 5 - completionInfo 259ms (± 0.73%) 250ms (± 0.39%) 🟩-9ms (- 3.36%) 248ms 252ms
Compiler-UnionsTSServer - node (v14.15.1, x64)
Req 1 - updateOpen 1,453ms (± 0.60%) 1,462ms (± 0.50%) +9ms (+ 0.63%) 1,447ms 1,476ms
Req 2 - geterr 3,548ms (± 0.72%) 3,357ms (± 0.50%) 🟩-191ms (- 5.38%) 3,323ms 3,397ms
Req 3 - references 234ms (± 0.38%) 206ms (± 0.59%) 🟩-28ms (-11.86%) 204ms 209ms
Req 4 - navto 174ms (± 0.82%) 165ms (± 2.29%) 🟩-8ms (- 4.73%) 160ms 180ms
Req 5 - completionInfo count 1,356 (± 0.00%) 1,356 (± 0.00%) 0 ( 0.00%) 1,356 1,356
Req 5 - completionInfo 56ms (± 3.73%) 65ms (± 5.19%) +9ms (+15.25%) 61ms 74ms
CompilerTSServer - node (v14.15.1, x64)
Req 1 - updateOpen 1,528ms (± 0.71%) 1,542ms (± 0.47%) +14ms (+ 0.93%) 1,524ms 1,555ms
Req 2 - geterr 2,332ms (± 0.68%) 2,190ms (± 0.30%) 🟩-142ms (- 6.09%) 2,176ms 2,203ms
Req 3 - references 246ms (± 0.44%) 215ms (± 1.03%) 🟩-31ms (-12.75%) 211ms 220ms
Req 4 - navto 184ms (± 0.65%) 178ms (± 0.90%) 🟩-6ms (- 3.43%) 174ms 180ms
Req 5 - completionInfo count 1,518 (± 0.00%) 1,518 (± 0.00%) 0 ( 0.00%) 1,518 1,518
Req 5 - completionInfo 55ms (± 1.35%) 61ms (± 0.00%) +6ms (+10.31%) 61ms 61ms
xstateTSServer - node (v14.15.1, x64)
Req 1 - updateOpen 2,144ms (± 0.73%) 2,048ms (± 0.91%) 🟩-96ms (- 4.47%) 2,008ms 2,080ms
Req 2 - geterr 760ms (± 0.52%) 746ms (± 0.33%) -14ms (- 1.83%) 742ms 753ms
Req 3 - references 67ms (± 2.61%) 73ms (± 2.18%) +7ms (+10.23%) 70ms 77ms
Req 4 - navto 230ms (± 0.96%) 221ms (± 0.63%) 🟩-9ms (- 3.87%) 218ms 225ms
Req 5 - completionInfo count 3,209 (± 0.00%) 3,149 (± 0.00%) -60 (- 1.87%) 3,149 3,149
Req 5 - completionInfo 279ms (± 1.01%) 277ms (± 1.79%) -2ms (- 0.72%) 268ms 286ms
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
Available Memory15 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hosts
  • node (v18.10.0, x64)
  • node (v16.17.1, x64)
  • node (v14.15.1, x64)
Scenarios
  • Compiler-UnionsTSServer - node (v18.10.0, x64)
  • Compiler-UnionsTSServer - node (v16.17.1, x64)
  • Compiler-UnionsTSServer - node (v14.15.1, x64)
  • CompilerTSServer - node (v18.10.0, x64)
  • CompilerTSServer - node (v16.17.1, x64)
  • CompilerTSServer - node (v14.15.1, x64)
  • xstateTSServer - node (v18.10.0, x64)
  • xstateTSServer - node (v16.17.1, x64)
  • xstateTSServer - node (v14.15.1, x64)
Benchmark Name Iterations
Current 51387 10
Baseline main 10

Startup

Comparison Report - main..51387
Metric main 51387 Delta Best Worst
tsc-startup - node (v16.17.1, x64)
Execution time 158.07ms (± 0.38%) 117.80ms (± 0.42%) 🟩-40.27ms (-25.48%) 115.63ms 127.81ms
tsserver-startup - node (v16.17.1, x64)
Execution time 222.85ms (± 0.30%) 199.11ms (± 0.36%) 🟩-23.74ms (-10.65%) 195.57ms 208.26ms
tsserverlibrary-startup - node (v16.17.1, x64)
Execution time 211.02ms (± 0.30%) 188.57ms (± 0.37%) 🟩-22.45ms (-10.64%) 185.48ms 197.64ms
typescript-startup - node (v16.17.1, x64)
Execution time 200.94ms (± 0.31%) 174.15ms (± 0.35%) 🟩-26.79ms (-13.33%) 171.22ms 181.93ms
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-generic
Architecturex64
Available Memory16 GB
Available Memory15 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hosts
  • node (v16.17.1, x64)
Scenarios
  • tsc-startup - node (v16.17.1, x64)
  • tsserver-startup - node (v16.17.1, x64)
  • tsserverlibrary-startup - node (v16.17.1, x64)
  • typescript-startup - node (v16.17.1, x64)
Benchmark Name Iterations
Current 51387 10
Baseline main 10

Developer Information:

Download Benchmark

@evanw
Copy link
Contributor

evanw commented Nov 2, 2022

Congrats! This is very exciting. I believe this PR also closes #39247.

@jakebailey
Copy link
Member Author

jakebailey commented Nov 2, 2022

It does! Thanks.

@jakebailey
Copy link
Member Author

Alright everyone, it's happening. See you on the other side.

@jakebailey jakebailey merged commit 1d96eb4 into microsoft:main Nov 7, 2022
@andrewbranch
Copy link
Member

Congratulations, Jake! 🌟

@jakebailey
Copy link
Member Author

jakebailey commented Nov 7, 2022

If you have a PR and are struggling to figure out how to fix your branches (after realizing what happened to main), here's what I am finding works the best:

  1. git merge d83a5e1281379da54221fe39d5c0cb6ef4d1c109 to get up to speed with main just before this change.
  2. Do git merge main, no options. The ones that try and ignore whitespace do not work.
  3. Use the new VS Code merge editor; it uses its own merge algorithm, and most of the time, you can just click "Accept Combination" and get the right result.

@jakebailey jakebailey deleted the typeformer-2 branch November 7, 2022 23:53
@LoganDark
Copy link

Late to the party, but if the size of your indentation is a concern, why switch from 4 spaces to 2 spaces instead of 1 tab?

@RyanCavanaugh
Copy link
Member

Switching from 4 spaces to 2 was just an artifact of switching emitters, not really anything intentional. We're not laser-focused on the smallest-possible non-gzipped artifact, otherwise we would of course use a minifier.

@LoganDark
Copy link

LoganDark commented Jul 10, 2024

Ah, so not necessarily a concern, just an interesting observation then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Relates to the public API for TypeScript Author: Team Breaking Change Would introduce errors in existing code For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet