Performance issue with React

[MicheleBertoli]

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]

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]

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

[adamchainz]

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

[thangngoc89]

You might be interested in this #604 (comment)

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

[spudly]

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]

@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]

@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]

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]

@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]

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

Less files to load when boostraping babel