Avoid calling fs.statsSync for non-existent paths

fs.existsSync can be significantly faster than fs.statSync when the path
argument doesn't exist since fs.statSync generates a stack trace. This
change avoids calling fs.statsSync when fs.existsSync returns false to
skip stack trace generation.

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 the !fs.existsSync guard, we saw:

- uvException and handleErrorFromBinding had less than 0.1% self-time
  percentages in the CPU profile.
- 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 (610fa28). 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.

 ## Other Notes

In theory, this change could make tsserver and tsc performance worse if
fileSystemEntryExists is called significantly more times with existent
paths than non-existent paths. We didn't observe this in our local
tests, but if that's a possibility it should be called out during
review.

Author: gluxon

src/compiler/sys.ts

@@ -1662,6 +1662,12 @@ namespace ts {
             }
 
             function fileSystemEntryExists(path: string, entryKind: FileSystemEntryKind): boolean {
+                // fs.statSync can be slow if path doesn't exist since Node.js generates a stack trace. Adding an
+                // fs.existsSync guard here can improve performance by reducing the number of times fs.statSync throws.
+                if (!_fs.existsSync(path)) {
+                    return false;
+                }
+
                 try {
                     const stat = _fs.statSync(path);
                     switch (entryKind) {