-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[DO NOT REVIEW] Performance testing minification #51153
Conversation
This step makes further commits look clearer by unindenting all of the top level namespaces preemptively.
This step makes all implicit namespace accesses explicit, e.g. "Node" turns into "ts.Node".
This step converts each file into an exported module by hoisting the namespace bodies into the global scope and transferring internal markers down onto declarations as needed. The namespaces are reconstructed as "barrel"-style modules, which are identical to the old namespace objects in structure. These reconstructed namespaces are then imported in the newly module-ified files, making existing expressions like "ts." valid.
This step converts as many explicit accesses as possible in favor of direct imports from the modules in which things were declared. This restores the code (as much as possible) back to how it looked originally before the explicitify step, e.g. instead of "ts.Node" and "ts.Symbol", we have just "Node" and "Symbol".
Now that we are modules, there's no reason to ban multiple namespaces per file; each file is its own scope and declaring a namespace won't merge it into any other files.
If these are regular comments, then they won't appear in our d.ts files. But, now we are relying on api-extractor to produce out final merged d.ts files, so they need to be present in the "input" d.ts files, meaning they have to be JSDoc comments. These comments only work today because all of our builds load their TS files from scratch, so they see the actual source files and their non-JSDoc comments. The comments also need to be attached to a declaration, not floating, otherwise they won't be used by api-extractor, so move them if needed.
This project is the same as the (soon added) typescript project.
This file is unreferenced, and just a subset of tsserverlibrary.d.ts. What I've heard is that this was intended to be used to detect protocol chagnes, but, no test actually references it, and we have separate infrastructure in place to ensure that protocol changes get the attention they need.
This configures the existing build tasks to use esbuild by defualt. If using the plain files is desired, passing `--bundle=false` will build using plain files and still produce a runnable system.
Profiling the build roughly half of the time spent loading the build is spent importing typescript.js, for this one function. Since this stack is already adding required devDependencies, switch readJson to use jsonc-parser (published by the VS Code team), rather than importing the entire LKG typescript.js library.
However, this script appears to not work as designed; the playground instead requests tsWorker.js, a file that we can't produce in our repo. Probably, we should just remove this script.
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 perf test this |
Heya @jakebailey, I've started to run the perf test suite on this PR at e0bfc76. You can monitor the build here. Update: The results are in! |
@jakebailey Here they are:
CompilerComparison Report - main..51153
System
Hosts
Scenarios
TSServerComparison Report - main..51153
System
Hosts
Scenarios
Developer Information: |
@typescript-bot perf test this |
Heya @jakebailey, I've started to run the perf test suite on this PR at 51e9c86. You can monitor the build here. Update: The results are in! |
@jakebailey Here they are:
CompilerComparison Report - main..51153
System
Hosts
Scenarios
TSServerComparison Report - main..51153
System
Hosts
Scenarios
Developer Information: |
@typescript-bot perf test this |
Heya @jakebailey, I've started to run the perf test suite on this PR at dc36aed. You can monitor the build here. Update: The results are in! |
@jakebailey Here they are:
CompilerComparison Report - main..51153
System
Hosts
Scenarios
TSServerComparison Report - main..51153
System
Hosts
Scenarios
Developer Information: |
esbuild vs esbuild + minify: Here they are:
System
Hosts
Scenarios
Summary
esbuild vs esbuild + minify + keepNames: Here they are:
System
Hosts
Scenarios
Summary
|
Minifying provides a slight speedup, but keeping the names for stack traces makes it a good bit slower. |
@typescript-bot perf test this |
Heya @jakebailey, I've started to run the perf test suite on this PR at 2382b93. You can monitor the build here. Update: The results are in! |
@jakebailey Here they are:
CompilerComparison Report - main..51153
System
Hosts
Scenarios
TSServerComparison Report - main..51153
System
Hosts
Scenarios
Developer Information: |
esbuild vs esbuild + minifyWhitespace: Here they are:
System
Hosts
Scenarios
Summary
|
No surprise, removing whitespace doesn't seem to change execution time in any meaningful way (but, does save us on space!) |
With microsoft/monaco-editor#3356 running on the playground, this sort of thing is now possible for us to do. Going to try running without and with minification enabled.