Workaround for spawning lots of MATLAB processes

[g-s-k]

Hi! I have a somewhat niche use case that I would like to validate and see if there is a good known workaround.

I maintain a MATLAB library that implements a widely-used API, and want to use a publicly available testing tool to prevent regressions from quietly making their way into my releases. I have this tool set up in my CI workflow, which works well, except it takes over an hour to complete.

The problem is that this testing tool operates by running your code as a child process for each test case, which in my case means creating a new MATLAB process over 300 times (!!!). Are there any flags or arguments that I could pass to the run-matlab-command executable to improve the speed, or maybe a different approach I could use to avoid spawning that many separate MATLAB processes?

[mcafaro]

Hi @g-s-k,

This sounds like something where the testing tool would need to be modified (or provide an option) to avoid launching a new MATLAB process every test case. I am not aware of a MATLAB startup option that would cause MATLAB to re-use an existing process rather than start a new one.

[jorgepz]

Hi @g-s-k , I don't have the most elegant answer but something that could be useful... If you want to use a testing tool probably using moxunit could be an option, as in here. If you want to use Matlab's run-command you could try what we did here to run a script with around 15 test cases. Both examples are running well in our Octave/Matlab library ONSAS.m. Cheers, Jorge

[acampbel]

Hi @g-s-k,

YMMV, but one thing you might be able to try which probably won't solve your problem but might alleviate it is to try out the new v2-beta branch of the setup-matlab action. This beta leverages a local install approach to getting MATLAB on the machine, so its startup may be faster than the v1 version. Given you may do 100s of MATLAB startups this might make a noticeable impact. Note that there is likely to be some overhead so the setup-matlab action may take longer. This overhead might be overcome in the overall savings. Also, you might be able to leverage caching in actions to improve the speed of this. Take a look at this repo to see an example of usage for this pilot version.

Best, Andy

[acampbel]

Also @g-s-k , is there any way that the test tool action you are using can parallelize the different invocations across GitHub workers? If so, that might be something to look into as well.

[g-s-k]

Thanks for the suggestions all - @acampbel the v2 beta cut execution time in half (!!!)