My playwright tests are taking the maximum slowMo time to execute certain steps but still execute them. EG:
page.evaluate
elementhandle.innertext
Our playwright.properties file is set to 500ms -
Each of the above steps takes around 502ms for me
If I ask a colleague who uses the EXACT same config from the same master branch, to run the same test, their steps take around 1-2ms
If I reduce slowMo to 0ms, my tests run perfectly fine and each step takes around 1-2ms
I've attempted to reinstall playwright and node modules in order to fix it, but no cigar.
I'm using an M1 Mac with 32GB RAM 16" screen
Had anyone else seen this or have any suggestions?
Related
Our react project has ~3000 jest tests. Most of them are just typical "render without crashing".
When we run npm test, the amount of memory used slowly climbs all the way to 22 Gb.
On machines with only 16 Gb, the tests grind the entire machine to a halt and take a very long time to finish.
What we have tried that has not worked or made the issue worse:
--maxWorkers=50% or --maxWorkers=4 etc
--runInBand (way too slow)
--detectLeaks (half our tests have memory leaks according to this experimental option, but we have no idea what they are or even if they are the cause of this problem)
The only thing that works is running the tests on a machine with a large amount of RAM (>= 32Gb).
Any idea on how we can reduce the amount of memory used by these tests?
We worked around this problem by splitting up the testing in multiple steps.
For example, if you have two source folders:
a/
b/
Then instead of running npm test, you can run it in two steps:
react-scripts test src/a && react-scripts test src/b
This will clear the memory used in each step.
In an effort to debug a production Angular issue, I'm trying to generate a source map for the project. As suggested on a number of SO articles I'm doing as below:
export NODE_OPTIONS=--max-old-space-size=2048
ng build --prod --sourcemaps
The choice of 2G RAM in the first line above is based on the fact I'm running this under VirtualBox on a laptop that I need to run other stuff on. It seems it's decided to steal a few gig of swap over and above that anyway, the HDD activity light has barely been off since the build started ...
The ng build process has been running for about 14 hours now, with practically that entire time having been stuck on this line:
69% building modules 1392/1397 modules 5 active ...b/node_modules/chartjs-color/index.js
This isn't a remarkably big project, how on earth is it taking this long?
I'll add that I don't really know Angular, just looking at this while the maintainer is on leave, so please don't assume I haven't missed anything obvious.
Literally all I want is the source map, not interested in anything else being built. Is there anything I can skip?
Edit:
I followed the one upvoted comment and tried restarting the build - same problem over and over.
Tried checking out to a fresh project and reinstalling node modules locally, as another dev suggested the fact I was checking out production atop of dev branch might be an issue - same.
Tried doubling RAM - same.
What appears to have fixed it is the addition of option --no-aot. But I don't know if that means it's a none-identical build, at least in terms of source map? Will find out I guess ...
We migrated our project from jasmine to jest couple month ago and now want to add some coverage in our TeamCity CI server. What we noticed is that for jest on a local dev's machine first run (with coverage) takes about 2-2.5 minutes and all consequent runs take about 20 seconds, but in TeamCity it takes about 6 minutes (with coverage) and only 1:30 without coverage. Is there any way to speed up tests with coverage for TeamCity?
It is an known issue [3] that coverage in jest makes running tests slower. However, there is no explanation what cures the issue. Only tip was to try -i flag on running the tests.
My source [2] tells why that flag improves the efficiency of tests all together. The flag disables multiprocessing and on some machines with limited resources (they say) this speeds up efficiency two fold.
My source [1] also tells the version after 22.4.4 has regression in efficiency (significantly slower than 22.4.4) and that was not fixed until article was written.
Also, they recommend in [1] to use Node but not JSDOM because Node is faster.
So, use:
// package.json
"jest": {
"testEnvironment": "node"
}
Hope these rocket speed your tests and you can taggle the loss of speed via coverage option on.
Sources:
[1] https://itnext.io/how-to-make-your-sluggish-jest-v23-tests-go-faster-1d4f3388bcdd
[2] Why does Jest --runInBand speed up tests?
[3] https://github.com/facebook/jest/issues/2586
Try adding the dotnet.cli.test.reporting parameter, which will
bring back to the normal running time.
Another possible workaround is to use vstest command instead of
test since it supports more precise test adapter path declaration.
I am having a big problem with meteor. Build process "meteor run" is extremely slow it takes about 10 minutes but that is not the bad part since it only happens once when starting.
The bad part is that it takes ~2 minutes to show my changes, file changed watcher taking too long.
When working with a basic example the feedback was way better ~5 seconds and it was workable but now that I am working on a real project it is impossible to make any progress.
I have around 40 packages in packages file and I am using latest meteor (1.3.2.4 at this time).
There were a ton of questions around this problem #4284 #6750, I don't know if there is any tip to bypass this issue ( changing any config,adding more RAM or anything ).
It there is no solution of that it would be helpful if there is a way to limit file watch to only a certain folder at a moment.
Update: I noticed there is ".node_modules" in the root of app can it be excluded from build process?
Thank you guys!
Try Webpack for Meteor.
It supports hot module reload, which can shorten rebuild times a lot. There are some differences compared to the default build process, so you'll need to learn a thing or two about it, but it could be well worth your time.
Try it by fetching kickstart-meteor-react-flowrouter from GitHub.
I am booting up a linux kernel using a full system simulator, and I'd like to run my benchmark on the booted system. However, when it boots up, it shows me this message: "clocksource tsc unstable" and occasionally it hangs in the beggining. However, sometimes it lets me run my benchmark and then probably it hangs in the middle since the application never finishes and seems it's stuck there. Any idea how to fix this issue?
Thanks.
It suggests that, kernel didn't manage to calculate tsc (Time Stamp Counter) value properly i.e value is stale. This usually happens with VM. The way to avoid this is to - use predefined lpj (loops per jiffy) as kernel parameter (lpj=). Try it, hope issue will be fixed!