Angular 12 + Jest 27 slow to start #2888
Labels
Comments
|
|
Restarting without reset cache: 14 minutes Still lots of performance errors. Output from Wallaby like this is HIGHLY suspect:
Once startup completes, this is a 4ms test in Wallaby realtime reports. ##Scrubbed Diagnostics |
|
You likely have a virus scanner running on your PC (even if it's Windows Defender). Can you please try disabling your virus scanner and see if the times improve? I am not expecting them to, but would like to check just in case. From your diagnostics report, it looks like you are using wallaby.js if (!process.env.WALLABY_NGCC_INITIALIZED) {
require('jest-preset-angular/ngcc-jest-processor');
// All worker processes will now have environment
// variable set and will not run the code again.
process.env.WALLABY_NGCC_INITIALIZED = true;
}
module.exports = () => ({
autoDetect: false,
trace: false,
debug: false,
configFile: "./jest.config.js",
slowTestThreshold: 60000,
testFramework: "jest",
env: {
type: "node"
},
workers: {
initial: 1,
regular: 1
}
}); |
|
Worker process set to 1/1 as asked: 13 minutes |
|
Setting Keeping worker process set to 1/1 as asked w/ this tsconfig change: 5.73 minutes I am seeing far fewer "long running code has been detected" errors too. |
|
I just closed my Powershell instances and stopped and started Wallaby. The whole 406 tests ran in 37.75 seconds. I can see the tests too. How is this even possible????? UPDATE 1Is Wallaby getting blocked up by another process somehow? Or was there an update that caused this? I couldn't even imagine a speed this fast. This is FAR faster than jest. And I just tried it again with powershell open. I started running UPDATE 2So I went ahead and stashed my wallaby config changes. Then stopped started it again. Super slow. So I re-applied my stashed changes. And it's still super slow. Reset wallaby cache. Still super slow. Lots of those "sandbox is not responsive errors" again. Again, I can't explain what happened. But I fear I have lost the amazing speed I had. And I cannot explain why or how to get back to that speed again. Update 3 (Major change)I don't know if I can disable virus scanner. I will have to work w/ Corporate IT to see. I've stumbled across a very clear problem that seems to have nothing to do w/ virus scanners. I let the machine sit for about 2 hours. Then I came back and ran STOP/START for Wallaby. It's fast again. Is there some type of caching process that takes a while to run?
As long as I do not reset the wallaby cache, the staggering difference in toggling Removing the workers setting makes no noticeable difference. |
There is no caching process except the one during a run after cache reset (it's mostly just Jest native cache that is used by Jest itself when ran by Wallaby).
So far it really sounds like an issue that may be caused by it (or some other process specific to the machine).
|
|
I want to be sure we are clear on one point. The ONLY change I make is:
So this one simple change I went from a 50 second run to an 11 minute run. If I flip it back to |
At this stage I don't have any good theory as to how exactly the setting affects Wallaby (and The setting may be producing some additional effect, however various timing/time reported anomalies, such as:
makes me think that it's not just the setting is involved, but there's some other machine/environment specific interference (such as virus scanner). Also according to your report the setting changes produce very different run time results: After you discovered the setting impact:
then after you
There must be something else responsible for the ~9 times difference in the test run duration caused by the same |
|
I'm using a corporate wallaby license. I could set up a test case on my personal machine, but I don't have a personal wallaby license. Is there a trial I could use or something? This problem is impacting at least 50 developers w/ Wallaby Licenses at my company. And maybe even more. And we might be taking on 200 more licenses in the near future. But if we can't get this thing to perform we are going to drop it. |
|
I created a new angular project to try to narrow this whole thing down. This project matches the same packages and the same number of unit tests. My Mac: Work machine (windows): I can't reproduce the issue so far on the simplified project. Even without using the specialized ngcc settings it's pretty fast. And this is on the work computer. |
You may copy your corporate license to your personal machine temporarily. Alternatively, you may request a trial license from our website.
We understand and appreciate your patience as we work through this with you. We tested the performance on one of our Windows machines with the following Wallaby configuration: // NOTE: also changed jest.config.js to check for the
// same environment variable before loading ngcc processor
if (!process.env.WALLABY_NGCC_INITIALIZED) {
require("jest-preset-angular/ngcc-jest-processor");
// All worker processes will now have environment
// variable set and will not run the code again.
process.env.WALLABY_NGCC_INITIALIZED = true;
}
module.exports = () => ({
autoDetect: true,
});
You will notice that the performance of Wallaby improves after multiple runs, but not after the first restart. The reason for this is that each Wallaby worker process that runs your tests is recompiling your project's tests on demand (the first time a test is run in a worker process). We thought that limiting the workers may improve performance (but it did not - see below):
Besides Wallaby's caching behaviour across multiple Wallaby worker instances, the performance of Wallaby and Jest is almost the same. It seems that the compilation time is what is slowing down tests in your project. Unfortunately if your compiler is taking a long time to compile your tests, there's not a lot that Wallaby can do about this. If I were in a similar position to you (slow project compilation times when running tests), I would seriously consider swapping out |
|
I was also reading a bit more about other people having problems with compilation times with Angular / ts-jest and came across a stack overflow article that suggested changing the ...
"angularCompilerOptions": {
"enableI18nLegacyMessageIdFormat": false,
"strictInjectionParameters": false,
"strictInputAccessModifiers": true,
"strictTemplates": false
}
... |
|
It seems the trick to all of this is STOP/START Wallaby 3x. I tried that w/ 3 different configurations. Messing w/ tsconfig. Using multiple workers. Using just 1 worker. None of this really mattered. What makes the most difference is that 3rd run. That's where I see speeds down to about 1 minute. I do see a slightly faster speed on that 3rd run w/ multiple workers. And there are diffs in the 1st/2nd run speeds. But on the 3rd they are ALL around the 1 minute mark. I let Wallaby run until it said finished and gave me a completion time. Then did another STOP/START. This is giving me very consistent results. The 3rd+ runs are good even after closing VS Code. As long as you don't do a cache reset. I'm not really sure, but messing around w/ the tsconfig, maybe wallaby config might also reset that 3x run requirement. That would make sense if the files all changed for some reason. 3 STOP/STARTS in a row without waiting to finish do not produce this result. I think you have to run it all the way through. That makes sense for the first run because that builds up the cache. I'm just not really sure why it's not super performant on the 2nd run. It seems to speed up about 50%, but not hit that sweet 1 minute-ish marks until run 3. Even now, I had a 17 minute run, 13 minute run, then a 1.12 minute run. I think that time I had changed wallaby.js, package.json and jest.config. Didn't do a cache reset. |
|
Can you please also try this // jest.config.js
module.exports = {
// ...
globals: {
'ts-jest': {
isolatedModules: true
}
}
}; |
|
w/ 5 minutes, 7 minutes, 36 seconds. |
|
I do see how the slow build can impact the tests. Is there a fix and/or explanation to the 3 run requirement I am seeing? Intuitively, I feel like Wallaby should have sufficient cache on run 2. |
I'd suggest to try babel (or swc) as Typescript compiler for Jest instead of
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Wallaby takes a good 10 - 15 minutes to start. Is this normal for the first run after:
Wallabyjs: Reset cache
Wallabyjs: Stop
Wallabyjs: Start
From the time I start it to the time the little loading thingy on the bottom right of VS Code goes away is a solid 10-15 minutes. Maybe 20. It's realllllly slow.
npx jestruns in 99 seconds. 406 total Tests. 111 Test Suites.VS Code: v1.63.2
I get a lot of this in red:
wallaby.js
The text was updated successfully, but these errors were encountered: