[core] Limit typescript:ci step memory limit

[LukasTy]

A continuation of #6850. This is an effort to try and reduce the flakiness of typescript:ci run, where it sometimes errors out with 137 error code signifying an out-of-memory issue.
It might not help in the long term.

Reducing concurrency to the number of CPU cores (2) seems to help the most with memory usage as it avoids the extra work that the OS scheduler needs to do in order to run 4 concurrent processes, but it does decrease the pipeline runtime. A middle ground between the two is 3 concurrent processes, that both produce a decent memory usage graphic as well as basically the same pipeline runtime as with concurrency 4.

• Upgrading node might help a bit with the runtime performance
• Or we might end up increasing the container to medium+ with 3 CPU cores and 6GB of RAM.
  The underlying problem is that the docker runs out of memory because tsc consumes quite a lot of resources and garbage collection does kick in.

But for now, we can try sticking with a cheaper container and seeing if the reduced node process heap size and even further reduced concurrency work for us. 🙏

Set the maximum allowed node process memory limit to 3GB and concurrency to 3 instead of 4.

P.S. Simply limiting the allowed memory for a node process is not the final remedy, because we also have other OS processes and especially GC consuming quite a lot of memory.

[mui-bot]

Netlify deploy preview

Netlify deploy preview: https://deploy-preview-8796--material-ui-x.netlify.app/

Updated pages

No updates.

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	642.6	1,060.4	642.6	828.78	190.147
Sort 100k rows	ms	603.8	1,297	1,297	974.26	223.933
Select 100k rows	ms	234.2	500	275.1	310.74	98.708
Deselect 100k rows	ms	150.1	313.8	274.3	251.32	63.576

Generated by 🚫 dangerJS against 91e6fa9

[cherniavskii]

Thank you!

[alexfauquette]

Would it somewhat make sense in the future to run git diff to know which projects are updated by the PR and run TypeScript only on the modified packages?

[LukasTy]

Would it somewhat make sense in the future to run git diff to know which projects are updated by the PR and run TypeScript only on the modified packages?

Hm. An interesting idea. I think that it would definitely make sense to optimize this case, but I don't think that diff would be enough, because of the relationship between packages. The complexity of how to identify when a certain package needs it might not be doable with simple static git diff.
That is the reason why we have TurboRepo or NX, where a relationship between packages is analyzed, and build/scripts can be run only on relevant changes, given that previous builds are being cached.