Is it worth recoding simpler versions of built-in MATLAB functions to speed up performance?
5 views (last 30 days)
Show older comments
Edward Tomanek
on 26 Nov 2022
Commented: Walter Roberson
on 27 Nov 2022
Using ADiGator, a package for the automatic differentiation of MATLAB functions, I stumbled across the issue that the package does not accept any files involving functions that take "varargin" inputs - i.e. I am having to copy and paste the code from a lot the built in MATLAB functions that take varargin, alter them and save them as local functions in my own directory. The resulting functions are significantly simpler but of course come with a smaller range of functionality.
This got me thinking - is there any point in doing this for most built-in functions? i.e. let's say I know that in a particular script/function that is being looped thousands of times, I will only need to use ode45 in a particular format (i.e. a certain number/type of inputs) - is there anything wrong with making a simpler version of the ode45 code that would, presumably work faster (although, of course, only being able to take that specific format of input arguments), to be used specifically for that purpose? I.e. is this a bad programming practice (in the same way as e.g. using global variables is advised against)?
0 Comments
Accepted Answer
Bruno Luong
on 26 Nov 2022
Edited: Bruno Luong
on 26 Nov 2022
You are free to strip down anything you want, just don't use the same name as the stock function.
As soon as you change the specification, functionality you ought to change the name of the function.
Though your example of ode45 is not well chosen to illustrate the point. ode45 is basically designed to be accurate but slow. It would not accelerate if you call it with certian type of input. If you want to accelerate, write your own ode solver and trade off the accuracy.
5 Comments
John D'Errico
on 26 Nov 2022
I would second and third the responses you have gotten here.
Changing provided code is a DANGEROUS thing. Never do that to provided code and leave the name the same. That is a really bad idea, as what you have removed was put there for a purpose.
But if you change the name, and test the hell out of it to insure it was done correctly, you can do it. Hacked code is your code to maintain and verify of course.
Beware when new releases come out, as now you need to reverify the code.
And as stated, those error checks you remove are rarely significant in terms of the savings, not when you consider the cost of your own time to write the hack, test it, insure it is correct, and then maintain it. In terms of an ODE solver for example, the error checks are done once, and if the computation time was at all significant, those checks were totally insignificant by comparison.
Walter Roberson
on 27 Nov 2022
There are times when it can make a real difference.
Suppose for example that you have code that loops doing lots and lots of ismember against a constant array. Every call it has to validate the parameter types and sizes. Then ismember checks to see if the second parameter is already sorted and if not runs a sort operation. Then it calls a binary search internal function.
You can reduce the overhead by batching more values in the first parameter. And sometimes that can work quite well. But sometimes you still end up with lots and lots of calls to ismember.
In the case of an already sorted second parameter, it turns out that you can reduce the overhead noticeably by not calling ismember and instead directly calling the internal binary search routine. The name of that routine has changed at least once so you need a unit test to be sure any given function name will work in a new release.
More Answers (0)
See Also
Categories
Find more on Loops and Conditional Statements in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!