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.
Component commits:
1582b76053 Revert "Add '(approximate)' to the beginning of quick info requests in PartialSemantic mode (#40061)"
This reverts commit 2426eb4980.
Co-authored-by: Daniel Rosenwasser <drosen@microsoft.com>
Component commits:
8f442baa3c Revert to including only open files in partial semantic server mode
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
Component commits:
6e5d75b58b Use isUncalledFunctionReference for aliases too
Fixes bogus deprecated notices on imports of functions with deprecated
overloads, but with some non-deprecated overloads.
Fixesmicrosoft/vscode#104238e2eb319e72 Just check all declarations, don't call isUncalledFunction
Co-authored-by: Nathan Shively-Sanders <nathansa@microsoft.com>
PR #38449 changed the second overload of the constructor for Int8,
Uint8, Int32, Uint32, Int16, Uint16, Float, Float64 -Array so that it no
longer includes `ArrayBufferLike`. It's just `ArrayLike<number>`.
This is fine except in the case that
the caller provides exactly `ArrayLike<number> | ArrayBufferLike`. This
PR adds ArrayBufferLike back so that the union is once again accepted.
This avoids a breaking change, in particular in one Microsoft-internal
codebase.
* Add separate flag serverMode for server mode to allow back compatibility
* Addressed code review feedback.
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
* 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>
* Updates Uint8ArrayConstructor to match MDN documentation.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/Uint8Array
```
new Uint8Array(); // new in ES2017
new Uint8Array(length);
new Uint8Array(typedArray);
new Uint8Array(object);
new Uint8Array(buffer [, byteOffset [, length]]);
```
While the previous constructors aren't significantly different from the new, it would prevent someone from doing `new Uint8Array(myBuffer, undefined, undefined)` since there was no overload that accepted undefined as a second parameter and buffer as first.
Fixes#38446
* Fixes constructor defenition for all other typed arrays.
* Renames property to `array` since it is no longer an `arrayOrBuffer`.
* 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 `?.`.
Brandon Cheng
TypeScript BotandAndrew Branch
Daniel Rosenwasser
Sheetal Nandi
Andrew Casey
Andrew Casey
Nathan Shively-Sanders
csigs
csigs
Andrew Branch
Wesley Wigham
Ron Buckton
Orta TheroxandAndrew Branch
Eli Barzilay
Micah Zoltu
