Closed HerbCaudill closed 4 years ago
Could you please try deleting your config and running Wallaby with automatic configuration to see if it helps?
If automatic configuration doesn't help, we'll investigate the performance for the project regardless, but when comparing with Jest, a better cold start test would be to compare running:
npx jest --collect-coverage --no-cache
(because Wallaby collect code coverage, while your current Jest config doesn't);Even with the test above, the instrumentation that Wallaby is doing is much more work than Jest's code coverage, so I'd expect Wallaby instrumented code to perform worse in long tight loops with thousands/millions of iterations (that seem to be very frequently used in this specific project). If it's the case, I think disabling instrumentation on code block level only for some of those loops may help.
Thanks for the sample repo. We spent a few hours reviewing your project today to identify why Wallaby is running slower than jest.
Using your project and your existing Wallaby configuration, Jest ran in ~25 seconds on our machines and Wallaby ran in ~60 seconds.
The main difference in execution times is a result of the code-coverage and other Wallaby features coupled with the large number of iterations that are a part of your mathematical helper libraries and your solutions. When Wallaby runs your tests, the additional operations it performs in addition to the large number of iterations in your code results in the increased execution time and this is expected.
There are a few recommendations that you may like to consider that would improve your Wallaby experience (and also any testing not using wallaby):
1) Wallaby workers
setting: we're not sure if you have already tuned these settings for your computer, but on our machines, we were able to reduce the execution time from ~60 seconds to ~40 seconds by increasing the initial
worker setting.
2) Test file structure: your test file structure is a little non-standard which doesn't allow for quick/easy isolation of tests. Your tests currently run using the executeTest
helper function. This makes test isolation using jest's .only
feature with Wallaby's test selection difficult/impossible. Being able to isolate specific tests/code that you're working on will reduce execution times.
3) It seems that you have a number of static "lib" type files that perform a fixed set of already well-tested operations (e.g. Prime number calculator, deepEquals, arraysEqual, factorial, millerRabin, etc.). Given the large number of iterations in these libs, and when used by files outside of these libs, it's unlikely that code coverage and instrumentation will be of use. We would recommend disabling instrumentation on these files (as per @ArtemGovorov's previous suggestion). If you had a mono-repo structure, you may like to have separate projects for each of these functions and then only start the wallaby tests if/when you're updating these libs.
Issue description or question
I'm working through Project Euler, and a number of the tests have a significant memory footprint. https://github.com/HerbCaudill/project-euler/tree/69ab1969b942d82d1bd7190aae0efd093e4a94bf
I can reduce the Wallaby time to around 1 minute by turning off instrumentation on all files:
... but if I do that, there's no real reason to use Wallaby in the first place.
Any ideas?
Wallaby diagnostics report