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

Are there further plans to improve Jest performance? #2171

Closed
davidtheclark opened this Issue Nov 27, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@davidtheclark

davidtheclark commented Nov 27, 2016

Just a question, not a bug report or feature request ...

I've now experimented with Jest on a number of different projects — projects of varying sizes and requirements (e.g. some using snapshots, some not; some doing real async work, some not) — and I have one consistent complaint: Jest is too slow. I'm filing this issue in order to see if this problem is on the team's radar, if there are intentions & plans to improve speed. I see so much advertisement of how fast Jest is, so I'm confused that my actual experience has been the opposite. (Is the advertised speed only in comparison to AVA?)

There's an issue or two and a PR pointing at the problem as it manifests in CI environments. But I'm also seeing this locally, though it's less a "bug" in this case because the tests still work, just slowly. Tests that blur by in Tape or Mocha plod along in Jest.

All the issues related to performance that I could find in this repo end up pointing at causes outside Jest. After my experiences, though, I question that dismissal. I've always found that Tape and Mocha are significantly faster in the same environment doing the same thing — never seen the opposite. When I have switched a project to Jest it has always been at the expense of performance.

I know this issue might seem "unactionable", but it's kind of my last-ditch effort to try to keep using Jest.

@davidtheclark

This comment has been minimized.

davidtheclark commented Nov 28, 2016

A wrinkle in the comparison with Tape above: Apparently there's some significant difference between what happens when running Tape with and without Babel, such that it can be faster with Babel when testing a huge amount of files o_O. Ran across this situation working on stylelint: it now turns out that although locally run Jest is significantly slower than babel-tape-runner was, it is actually faster than Tape itself without Babel, once the total test count passes several thousand or so ¯(°_o)/¯. Unfortunately, still can't use Jest on CI because of memory failures ...

Anyway, I'm very sorry if any of this comes off as me being a stupid jerk. I clearly don't really understand what's going on, and am frustrated that these days I seem to be butting up against the limitations of each JS test runner I try; so I'm just hoping Jest can end up being the magic bullet that solves this 😬

@probablyup

This comment has been minimized.

Contributor

probablyup commented Nov 29, 2016

Do you use the JSDOM environment? There are startup costs associated that are not easily remedied. Try the node environment if you don't need the DOM.

@davidtheclark

This comment has been minimized.

davidtheclark commented Nov 29, 2016

@yaycmyk Thanks for chiming in. Yeah, I've used Jest in both environments. I'm ready to accept some slowness when using JSDOM and snapshots, because I know JSDOM can be slow and there's some I/O involved when reading snapshots. However, it's worth noting that before using Jest I was using JSDOM in Mocha with expect-jsx assertions, and those moved noticeably faster than the Jest tests that replace them. So I wonder if there's room for improvement, I guess.

@thymikee thymikee added the Question label Dec 8, 2016

@thymikee

This comment has been minimized.

Collaborator

thymikee commented Jan 10, 2017

@davidtheclark thanks for all the concern! But I'll close this issue, as we're constantly seeking to optimise performance. Hope you don't mind.

We've recently tracked a memory-leak in JSDOM which slows us down, but we believe this will be addressed soon.
Also the watch-mode has been rewritten with some nice perf gains on larger repositories, ready to be released in the next major version.

If you have any ideas on how to improve it further, please do so in separate issues 🙂

@thymikee thymikee closed this Jan 10, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment