Profiling
Occasionally I try to work around problems with MATLAB’s shitty slow performance by using its “profiler.”
A profiler is simple in concept: It records how much time a program spends in various functions, so you can tell which ones are slowing you down. There are a couple of different ways to implement a profiler: You could arrange to interrupt the language runtime every millisecond or so and see what functions you’re in the middle of executing. Alternately, you could arrange to record the time every function call begins or ends. Both these techniques involve either instrumenting the runtime, or concurrency and runtime introspection — that’s the kind of runtime stuff that MATLAB doesn’t provide users access to, so instead of being able to actually write a profiler, we have to rely on what profiling ability TMW’s programmers have already built into the runtime.
But fundamentally, that’s the hard part. After you’ve instrumented your runtime and are recording data while the program runs, everything after that is just tabulating and adding up numbers.
Which leads me to ask, how the fuck is MATLAB fucking up at the “adding up numbers” part so badly?
No, I do not have 36 CPUs in my machine, and mainLoop>go does not recurse on itself at all, either.
More after the jump…Oh! One twentieth of the calls to require take 50 times as long as twenty twentieths of them.
In a new profiler run, everything that calls mainLoop>go is accounted for, Interestingly, we conclude this function accounts 94% of its time not being called at all.
