[core] Fix test-types out of memory error

[LukasTy]

Try tackling the same yarn error code 137 appearing when typescript:ci is being run.
This error is thrown when the system runs out of physical memory (RAM).

Done some testing using a few different configurations:

• concurrency 4 -> 72.68s
• concurrency 5 -> 69.43s
• concurrency 7 + medium+* -> 76.88s
• concurrency 6 + medium+* -> 57.07s

• medium+ is a one step bigger container: 6GB RAM & 3-core CPU instead of 4GB RAM & 2-core CPU.

Based on the above experiments it seems that firstly going with a simple approach of reducing the concurrency is perfectly viable. Upsizing the container does yield a bit better performance, but if it costs more to us—it does not seem like it is worth the trade-off. At least at the moment, because we are not able to consume >75% of RAM.
Besides, lower concurrency does not necessarily mean longer task runtime as seen by examples and local experiments.

In any case we have somewhat low amount of cores and spawning a lot of processes requires a lot of task switching to happen when executing tasks. In our case—each of the task runtime is quite small and can benefit from lower concurrency and less CPU scheduler priority switching needed.

Related to mui/material-ui#31332

[mui-bot]

	Messages
📖	Netlify deploy preview: https://deploy-preview-6850--material-ui-x.netlify.app/

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	696.4	1,177.3	726.1	865.46	186.46
Sort 100k rows	ms	630	1,286.4	1,286.4	1,007.6	217.042
Select 100k rows	ms	226	295.5	247.9	256.48	24.155
Deselect 100k rows	ms	158.9	304.9	203.5	220.48	51.914

Generated by 🚫 dangerJS against c3aa818

[cherniavskii]

The test results are quite surprising!
Let's see if the issue returns

[flaviendelangle]

I sometime have crashes on yarn typescript on my local machine with 16go of RAM
I would not be surprised if we had a deeper problem somewhere

But I'm fine with starting like this 👍

[LukasTy]

The test results are quite surprising!

Yup. Naturally there are run-to-run variances on it's own. Also—we provide --no-sort argument, which further increases the variance of time each run might take depending on the order of packages scheduled for execution.

Testing most accurately would require the --no-sort argument removal, but in any case, it seems that with our current package sizes—lower concurrency is perfectly fine and even going down to 4 yields basically same results.

[LukasTy]

I sometime have crashes on yarn typescript on my local machine with 16go of RAM

Do you have memory swap turned on?
I'm not sure, but I have a feeling that docker instances do not have memory-swap turned on and it naturally crashes the process when system runs out of available memory.

[flaviendelangle]

Do you have memory swap turned on?

Yep

[oliviertassinari]

Looks great 👍