The exception thrown by Node.js's fs.statSync function contains a stack
trace that can be expensive to compute. Since this exception isn't used
by fileSystemEntryExists, we can safely set Error.stackTraceLimit to 0
without a change in behavior.
---
A significant performance improvement was noticed with this change while
profiling tsserver on packages within a proprietary monorepo.
Specifically, my team saw high self time percentages for Node.js's
uvException and handleErrorFromBinding internal functions. These
functions are executed within fs.statSync when it fails to find the
given path.
https://user-images.githubusercontent.com/906558/90183227-220cb800-dd81-11ea-8d61-f41f89481f46.png
fs.statSync: https://github.com/nodejs/node/blob/v14.4.0/lib/fs.js#L1030-L1037
handleErrorFromBinding: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/fs/utils.js#L254-L269
uvException: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/errors.js#L390-L443
## Measurements
After adding Error.stackTraceLimit = 0, we saw:
- For a large configured project with 12,565 files, tsserver reached the
projectLoadingFinish event 48.78% faster. (~46.786s vs ~31.447s)
- For a medium project with 7,064 files, tsserver was 25.75% faster.
(~20.897s vs ~16.618s)
- For a small project with 796 files, tsserver was only a negligible
3.00% faster. (~3.545s vs ~3.442)
Measurements were taken on macOS 10.15.6, Node.js 14.4.0, and a recent
master commit of TypeScript (610fa28d). The average of 3 runs before and
after this change were taken.
I would normally include .cpuprofile and isolate-*-*-*.log files, but
can't post them publicly in this case. If there's any other summaries
the TypeScript team would be curious about I can report them.
## fs.statSync Misses
Within our monorepo, the fs.statSync misses were mostly searches for
alternative file extensions of module imports.
- For node_modules imports, a lot of .ts/.tsx lookups failed until the
.d.ts file was found.
- Within projects with a lot of JSX files, .ts files were looked for
before finding the .tsx version.
- In the medium scale project mentioned above, a total of 38,515
non-existent files were queried during createProgram.
* Bind alias ThisProperty assignment declarations
This is a quick prototype that does the wrong thing at the wrong time
with the wrong technique.
* Preliminary checker handling for aliases
Duplicative and untested, but I think I updated all the places that need
updating.
* new is error; old one should not have been removed
* I don't even know what's happening with this test
* cleanup and testing in the checker
* binder: use lookupSymbolForNameWorker instead of mutable
This should have about the same behaviour and is much easier to
understand.
Also refactor common code a bit.
* Shorter name of lookupSymbolForName
Once upon a time there was a parent/worker function, but now it's just a
single function again. No need for the -Worker suffix.
* remove oodate comment
* fix switch-case-break lint
* Refactor and move functions
* Rename and improve type of getContextualTypeForAssignmentDeclaration
* Preserve the variable name when exporting an arrow or anonymous function
This allows the browser or node to properly name the (arrow) function
* Updated tests to reflect previous change
* Remove duplicated comment
* Transforms variable.initializer using moduleExpressionElementVisitor
* PR feedback: rbuckton
- Use isArrowFunction and isFunctionExpression
* PR feedback: rbuckton
- Consider ClassExpresion, they can also be named based on the
variable.
* Use isUncalledFunctionReference for aliases too
Fixes bogus deprecated notices on imports of functions with deprecated
overloads, but with some non-deprecated overloads.
Fixesmicrosoft/vscode#104238
* Just check all declarations, don't call isUncalledFunction
* Limit auto import provider project size
* Add test
* Make option configurable
* Fix test
* Only bail when setting is auto
* Fix other test
* Update API baseline
* added Error 5084 to diagnosticMessages.json
* added test case errorForBareSpecifierWithImplicitModuleResolution1 to tests/cases/compiler
* modified checker.ts to report error 5084 when classic resolution and incorrect path are used
* added baseline changes
* passes all test cases including src/testRunner/unittests/ tests
* Update with feedback
* Make it check whether it is the right module resolution kind
* Use the right diagnostic message in tsserver tests
Co-authored-by: Meera Shivakumar <mshivaku@umich.edu>
Co-authored-by: Orta <git@orta.io>
* Fix this parameter emit for JSDocFunction types
Previously, parameters with names that were not `new` were treated like
rest parameters. This is incorrect: parameters with the name `this`
should emit a `this` parameter.
Fixes#38550
* ❤️ quote style
Use only the relevant declarations (by collecting them in the for loop),
and use `declaration` if `getNameOfDeclaration` didn't work (useful for
`export default` with anonymous functions).
Fixes#39804.
Also, use `nodeIsPresent` once, and a random `?.`.
* Hack everything together
* Add test
* Remove realpath from program
* Ensure symlinked directories are directories
* Revert unnecessary change
* Update baselines
* Use host program realpath on AutoImportProviderProject files before program creation
* Which fixes hasRoots() too
* Apply suggestions from code review
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Lint
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
* Fix#37948
* Fix formatter skipping tab/space fixup on comments, handle trailing commas in list closing line count.
Fixes#37944
* Add newline between imports and main body of new file in moveToNewFile
Fixes#37941
* Update baseline (probably broken before?)
* Use disableReferencedProjectLoad to stop loading child projects to allow users to disable loading large solutions
Fixes#39144
* Handle indirect references
* PR feedback
* Add tests corresponding to repro from #37928
* Triple slash references must resolve against the resolved file name (.d.ts and not original source file) since they are rewritten in the .d.ts emit
* Remove the scenario not fixed in this PR
