Skip to content
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

Performance: --require #808

Closed
vjancik opened this issue May 4, 2016 · 3 comments
Closed

Performance: --require #808

vjancik opened this issue May 4, 2016 · 3 comments

Comments

@vjancik
Copy link

vjancik commented May 4, 2016

Does preloading a module using --require improve the startup speed of the tests? E.g. does the loaded instance get distributed to the workers?

If not, what good is it, other than babel-register?

@spudly
Copy link
Contributor

spudly commented May 4, 2016

Unfortunately, using --require actually slows it down, because it get's required in each fork (not in the main process). In my experience, requiring --babel-register actually makes it twice as slow.

@forresst
Copy link
Contributor

forresst commented May 4, 2016

See Recipe babelrc, section Transpiling Sources :

Note that loading babel-register in every forked process has a non-trivial performance cost. If you have lots of test files, you may want to consider using a build step to transpile your sources before running your tests. This isn't ideal, since it complicates using AVA's watch mode, so we recommend using babel-register until the performance penalty becomes too great. Setting up a precompilation step is out of scope for this document, but we recommend you check out one of the many build systems that support Babel. There is an open issue discussing ways we could make this experience better.

@jamestalmage
Copy link
Contributor

If not, what good is it, other than babel-register

It could be used for other things besides babel-register.

Registering, your desired Observable implementation via any-observable for instance.

It has nothing to do with performance (though using it can have performance side effects, as @spudly mentioned). Use npm@3 to minimize those, and know we are working on ways to improve the performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants