profiling function call in backgroundpool

I have two versions of my function (OLD and NEW).

I am trying to optimize the speed of my code. In normal mode, NEW runs faster than OLD.

When I use parfeval to run the functions in the backgroundpool, OLD is faster than NEW.

How can I find out what slows down NEW in the backgroundpool?

[Rik]

I created my own code coverage and timing tool, because I have code branches for old Matlab releases and for GNU Octave. It is fairly slow and imprecise, which is why I wouldn't call it a profiling tool.

You could consider doing something like that yourself. One idea would be to have a function with a persistent variable log the time spent on specific lines (either with tic and toc, or with clock). Just before the worker shuts down you write this log to file. Have a each worker generate a unique file name to avoid file conflicts. You can then tabulate the results.

My tool works a bit like that (it also includes a dbstack call to help me track subfunction calls). I hope someone suggests a better way to do this so I can steal that idea.

[Oliver Jaehrig]

Can you check if you can use:

https://www.mathworks.com/help/parallel-computing/mpiprofile.html

[Rick Amos]

The mpiprofile feature is not yet supported for thread-based pools, however the underlying profile feature has been since R2023b. If you have R2023b or later, you can do the following to profile code running on the background until we do have something like mpiprofile:

info = fetchOutputs(parfeval(backgroundPool, @profileMyExample, 1));
profview(0, info);

function info = profileMyExample
profile("on");
runMyExample;
profile("off");
info = profile("info");
end

function runMyExample
% Some code to be profiled
for ii = 1:10
    eig(rand(1000));
end
end

In terms of the differences in performance, the main suspect would be whether the function is itself implicitly multi-threaded and something changed when running from the background. If you do maxNumCompThreads(1), does the performance match between running normally and running in the background?

Answer 1

[Matthias Wurm]

Thank you for your valuable comments.

Rick Amos' profiling example in particular was very helpful. I was able to implement it and find the error.

The error was mine:

While the comparison was fair in non-parallel mode (same conditions), it was no longer fair in parallel mode (backgroundPool). The test result was therefore meaningless.

After I was able to clarify this, NEW now always runs faster than OLD.

Many thanks for your support.