Very slow startup time

[cspotcode]

Prerequisites

• Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
• Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
• 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
• Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description

mocha's CLI startup time is very slow. findup-sync appears to be a culprit, coupled with the fact that mocha loads findup-sync twice since it spawns a child-process.

node -e "require('findup-sync')" is taking at least half a second on my Windows box. Windows suffers from higher per-file FS overhead, but I think this is still way too slow, considering that findup is barely doing anything.

findup-sync indirectly loads fast-glob, micromatch, and nanomatch, which internally do some sort of initialization of compilers and parsers for their glob pattern handling. I think these compilers are meant to be super-fast, but ironically all the extra complexity means they initialize pretty slowly. mrmlnc/fast-glob#92

Would you accept a PR that replaces mocha's usage of findup with a faster while() loop?

Are there specific globbing behaviors you want to preserve? I see that findup-sync is used for .mochrc discovery and package-file discovery. The former definitely doesn't need glob support; I'm unsure about the latter.

Steps to Reproduce

I've been adding console.time() and console.timeEnd() statements to mocha's code to track down which require() calls are the slowest.

Versions

mocha v6.0.0-1
node v11.3.0

Additional Information

[boneskull]

If you can improve performance and keep maintenance overhead to a minimum, go for it. We do use findup-sync in a couple places, though, so use care.

Generally, I'm opposed to handrolling solution like this, since we've been (and continue to be) bitten by oversimplified solutions to complex fs-related problems. If you can find a suitable module in the ecosystem which is more performant for our use case, please prefer that. Keep in mind that we may want to do per-directory config files in the future... and Mocha also runs in the browser, so whatever you do should be isolated in such a way that the browser doesn't choke on it.

[cspotcode]

@boneskull thanks, I'll see what I can find.

findup-sync is used in 2 places: (ignoring tests, where it can remain as a devDependency)

a) discovering the location of a .mocharc file
b) discovering the location of package.json

For (a), you look for a hard-coded list of non-glob filenames.

For (b), are globs indended to be supported, or is that merely a coincidence? In other words, if I find an alternative module that does not support globs, is that a blocker?

There is no documentation for the package configuration flag, so I don't know if it must support globs or not. It seems like you do not want it to support globs, since the example given is not a glob.

Documentation for the --package option does not mention globs: https://mochajs.org/#custom-locations
Example of the --package option is not a glob: https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.yml#L32

[cspotcode]

I'm investigating cosmiconfig as an alternative. It handles all the situations mocha cares about: discovering a config file, using different loaders based on file extension, and pulling the mocha property off of a package.json.

I filed a few issues to support mocha's use-case:
cosmiconfig/cosmiconfig#176
cosmiconfig/cosmiconfig#172

[juergba]

see #3830