Comments on: Speeding-up builtin Matlab functions – part 1

By: Matlabler

Matlabler — Fri, 17 May 2019 12:00:50 +0000

Great tip, thank you! I speeded up the rangesearch function this way. I just replaced it with pdist2(X,Y,distance,’RADIUS’,radius); and now I save 93% of the time it takes before. So now I only need about 4 hours for my calculation, before it took over 36 hours!!

Thanks!

By: Gregor Lehmiller

Gregor Lehmiller — Wed, 02 May 2018 22:31:35 +0000

Unfortunately, while it has added many features, the Matlab stats/machine-learning toolbox has been going backwards for a number of versions. In particular, the obsession with making everything a class has made code transparency and algorithm inspection a nightmare. The related attempt to make classes have a jack-of-all-trades capability has slowed things down even more.

In our applications, we are now frequently either writing our own statistical/numerical routines (usually in C-mex) or borrowing standard algorithms. At some point we may abandon ship to a different platform – for example, just stay in C/C++ with a Python overlay.

This has been very disappointing development in Matlab evolution, especially for those of us for which speed is critical.

By: Michelle Hirsch

Michelle Hirsch — Tue, 01 May 2018 16:47:42 +0000

Thanks for this post, Yair. I’ve passed along the issues to the development team.

By: Sam Roberts

Sam Roberts — Tue, 01 May 2018 10:55:42 +0000

> single-character global variables There's really no excuse for this. Quite apart from the performance issues that you bring out, there will be newbie programmers all over the place that will be using global a in their code. This is going to clobber it, they'll have no idea what happened, and it will be very hard for them to figure it out - especially if they trust MathWorks code not to do bad things like that. And if/when they do figure it out, they're going to be pretty angry with MathWorks. At the very least, even if the developer felt a genuine need to use a global, they could have named the variable something like _internal_param_a to reduce the likelihood of a name clash.

By: Yair Altman

Yair Altman — Mon, 30 Apr 2018 16:23:25 +0000

In reply to Cris Luengo. @Cris - you are absolutely right that persistent is better for caching than global in most cases; and in the rare cases where global vars are used, they should be named appropriately, with meaningful names that are longer than a single character. In the code I wrote for my client this is indeed the case - I just simplified it in this article, following the [very bad] coding conventions that the original MathWorker developer used in these functions. In hindsight this was a bad decision because it is misleading (as your comment has shown), so I have now updated the text accordingly. Thanks for pointing this out.

By: Cris Luengo

Cris Luengo — Mon, 30 Apr 2018 16:07:44 +0000

`global s` and `global options`? Yes, that’s not going to give any problems at all.

Why not use `persistent` to cache data?

By: Hanan Kavitz

Hanan Kavitz — Mon, 30 Apr 2018 07:09:48 +0000

Hi Yair,

Loved this post.
Here’s another caching example I recently implemented:
It turns out we use verLessThan function alot in our code base. I discovered that some of our UI’s call this function many times over and over until the UI is finally visible. It was one of the bottle necks for fast and UX friendly UI’s.
Since the version of a toolbox can’t just change in the middle of MATLAB process there is no need recalculating it over and over again.
I created verLessThan_fast function that caches the results of verLessThan by toolbox and version number first time this function is called and returns cached data on every consecutive call.
I got a very significant UX improvement.