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 issue with React #669

Closed
MicheleBertoli opened this issue Mar 22, 2016 · 10 comments
Closed

Performance issue with React #669

MicheleBertoli opened this issue Mar 22, 2016 · 10 comments

Comments

@MicheleBertoli
Copy link

Description

We started using AVA in our application and we found that the more React components we tested, the slower the tests became.
Obviously, we expected a small increase for each test but 120s for one hundred files seemed too much.

So, I created a simple test case to make some benchmarks:
https://github.com/MicheleBertoli/react-test-perf

N. of tests Time (s)
1 1.71
10 11.04
100 118.59
1000 🔥

Are we doing something wrong?
Is there a way to optimise the execution?
It looks like the largest amount of time is spent even before running the tests (maybe transpiling?).

Environment

Node.js v5.7.1
darwin 14.5.0

@mattecapu
Copy link

I think it would be highly beneficial to support a --max-forks limit to limit the spawning... When more than 1-2 process per core are running the parallelism perf bonus is lost. On my single-core CPU the whole thing simply freeze.
Happy to help on this.

@spudly
Copy link
Contributor

spudly commented Mar 22, 2016

I've been investigating a similar performance issue. Perhaps this is my problem too...

@adamchainz
Copy link

--max-forks with a sensible default of say 2 per core is the way forward, too many processes per core kills anything multithreaded

@thangngoc89
Copy link

You might be interested in this #604 (comment)

I'm testing React (and others memory hungry function).

@spudly
Copy link
Contributor

spudly commented Mar 22, 2016

I cloned the above repo and hacked away at it for a while. One initial finding is that if I remove the requirement to transpile the react component (by writing it using vanilla js), and remove babel-register from package.json/ava/require, the time goes down from 52.22 seconds to 23.84 seconds (running 100 ava tests).

That's a drastic improvement in performance. The takeaway here is that each and every fork has to load it's own copy of babel-register, and since babel is so big, it makes it take over twice as long to run the tests.

@jamestalmage
Copy link
Contributor

@spudly
An alternative to writing vanilla js would be to use a build step to transpile your sources.

lib/
  foo.js
test/
  test-foo.js
build/
  foo.js

And test-foo.js does this:

 import foo from '../build/foo.js'

That's definitely not ideal, but you get to keep writing in ES2015 (:+1:), and there is a very good chance we will improve this performance bottleneck in the future.

@lucasmotta
Copy link

@spudly @jamestalmage that's a good point and def removing the babel step will help a lot. But in the other hand, tape and mocha are also transpiling the source code, but they manage to keep it very fast.

But the issue #577 looks very promising thou.

@jamestalmage
Copy link
Contributor

tape and mocha are also transpiling the source code, but they manage to keep it very fast.

That actually depends on your test layout. If you have a few test files with lots of slow tests in each file, then AVA still is faster even though you need to load babel-register in every test. If you have lots of files with just a few tests each, then yes, babel-register costs you big. The solution above should be about the fastest option available (with the downside of requiring extra setup).

Also, I would try on Node 5.9. I think there have been some speed improvements. (And always use npm@3).

@novemberborn
Copy link
Member

@MicheleBertoli thanks for raising this and pushing AVA to its limits :) As mentioned #577 discusses ways to avoid the per-fork babel-register overhead. We're tracking fork performance issues in #78.

@thangngoc89
Copy link

For the babel problem, I found this interesting project https://github.com/hayeah/babel-fast-presets

Less files to load when boostraping babel

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

8 participants