# Which MATLAB operations/functions need speeding up?

21 ビュー (過去 30 日間)
Oliver Woodford 2013 年 11 月 20 日

When using MATLAB, I sometimes come across a performance bottleneck caused by functionality that I believe could be much faster. It is worth bringing these observations to the attention of TMW.
Do you know of any such functionality?
Upvote the suggestions of others you'd like to see TMW tackle.
##### 1 件のコメント表示非表示 なし
Daniel Shub 2013 年 11 月 20 日
Jan provided a number of examples in this answer.

サインインしてコメントする。

### 回答 (23 件)

Matt J 2013 年 11 月 21 日

SUB2IND and IND2SUB are very frequently used functions. Yet they are still implemented only in Mcode, rather than as compiled builtins.
Even better would be to allow numeric arrays to accept lists of subsripts, e.g.,
A({I,J})
could be equivalent to A(sub2ind(size(A),I,J)) instead of having to convert manually to linear indices.
##### 2 件のコメント表示非表示 1 件の古いコメント
John D'Errico 2015 年 6 月 1 日
I'd very strongly argue that this is how indexing SHOULD be done for scattered indices.

サインインしてコメントする。

Oliver Woodford 2013 年 11 月 20 日
BSXFUN with builtin functions
Bsxfun is useful in that it allows us to vectorize elementwise operations between arrays of different sizes, without using repmat, and the additional time and memory that that requires, to make the arrays the same size. It is therefore disappointing to find that the repmat approach can sometimes be significantly faster, even when using builtin functions. For example:
>> A = uint64(rand(10, 1, 100) * (2 ^ 64));
>> B = uint64(rand(10, 100, 1) * (2 ^ 64));
>> disp(timeit(@() bsxfun(@bitxor, A, B)))
0.0124
>> disp(timeit(@() bitxor(repmat(A, [1 100 1]), repmat(B, [1 1 100]))))
2.7831e-04
In this case the repmat approach offers a 45 times speed up! (Note that I'm using the repmat from the Lightspeed Toolbox, as mentioned in another answer).
##### 3 件のコメント表示非表示 2 件の古いコメント
Matt J 2016 年 9 月 19 日
In release R2016b we support implicit expansion in a number of operators and functions.
That's great! Although, I can imagine people sticking with bsxfun for quite some time to stay compatible with older versions.

サインインしてコメントする。

Cedric Wannaz 2013 年 11 月 20 日

EDITs
I found a series of non-built-in functions with bottlenecks over the years, which were or will be converted to built-ins. When looking at the source code, most times the reason was the presence of "slow" tests like ISMATRIX. I usually rewrote these functions specifically for my applications, without unnecessary (in my context) tests. Even for built-ins though, I would appreciate having the possibility to set JIT directives at the beginning the the code, which allow e.g. to disable these tests (or to enable even heavier ones during the development phase). It could be interesting as well to set directives on a per function call basis, e.g.
outVars = someBuiltin[JIT directives](inVars) ;
[a,b,c] = foo[argchk=0](x,y) ; % Or CSL of params/values,
% or more elaborate.
Along with this could come an "advanced" version of the documentation which shows pseudo-code for each function with directive names for enabling/disabling blocks. One great improvement would be to have an indication about the method/algorithm as well.
I propose to put directives before the parentheses, so there is room for implementing the indexing of the output of functions later, e.g.
lastCol = foo[argchk=0](A,b)(:,end) ;
or even accessing methods/properties of object outputs (here, directives are params/values)..
surfaceArea = grid.getCell[argchk,0](28).getSurfaceArea() ;
Finally, it's a different type of optimization, but TRY statements could take arguments setting max memory usage or max execution time:
try('maxExecTime', 1e4, 'maxMemoryUsage', 5e9)
...
catch ME
...
end
##### 2 件のコメント表示非表示 1 件の古いコメント
Cedric Wannaz 2013 年 11 月 21 日
This is neat actually. I will have a look tomorrow. Thanks!

サインインしてコメントする。

Walter Roberson 2013 年 11 月 21 日
OOP used to be very slow; I hear that it is faster now, but it needs to become competitive in speed, at most a small percentage slower. Otherwise, people are not going to bother learning it and using it.
##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Royi Avital 2014 年 8 月 26 日
The function `im2col`.
See here:
Those two functions are crucial for "Patch" and locally adaptive image kernels. And they take too long.
I think they should be rewritten using MKL / IPP and get multi threaded care.
##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Oliver Woodford 2015 年 4 月 13 日
CROSS
It is shameful how slow this basic function is. I wrote my own (still in standard MATLAB), and it was 5 times faster. But as a builtin it could be much faster still.
##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Matt J 2013 年 11 月 20 日

ACCUMARRAY
I still have my doubts about whether accumarray is maximally optimized, based on this example. Even if it is as close to optimized on the CPU, there's so much more I could do with it if I had GPU support.
Finally, the 4-argument syntax
accumarray(subs,val,[],fun);
can definitely be better optimized to handle certain choices for fun. Following are some examples of how I workaround the slow behavior of fun=@std and fun=@mean
n = 1e7; % size of daily data
idx = randi(65160,n,1); % 65160 is for 181*360 latitude and longitude
data = randn(n,1);
%%%%%%%%%%%MEAN
tic
accummean = accumarray(idx,data,[],@mean);
toc
%Elapsed time is 2.649816 seconds.
tic
N = accumarray(idx,1);
accummean = accumarray(idx,data)./N;
toc
%Elapsed time is 0.248310 seconds.
%%%%%%%%STD
tic
accumstd = accumarray(idx,data,[],@(x)std(x,1));
toc
%Elapsed time is 4.706466 seconds.
tic;
N = accumarray(idx,1,[]);
idxn=N~=0;
EX= accumarray(idx,data,[]);
EX2= accumarray(idx,data.^2,[]);
accumstd=sqrt(N.*EX2-EX.^2);
accumstd(idxn)=accumstd(idxn)./N(idxn);
toc
%Elapsed time is 0.406712 seconds.
##### 2 件のコメント表示非表示 1 件の古いコメント
Oliver Woodford 2013 年 11 月 20 日
Yes, accumarray is definitely ripe for improvement. If the 'fun' argument could also be a function name (string) then such optimisations would be possible internally. Same for bsxfun.

サインインしてコメントする。

Matt J 2013 年 12 月 4 日

Operations that modify object properties
obj.prop(i)=1
always create temporary deep copies of the entire property even if prop is a huge array and i is a scalar index. This, of course, slows things down.
I believe this might be done to accomodate the flexibility of property set and get methods. See, for example, this thread, but there should be a property Attribute that can tell MATLAB that prop can have normal in-place access behavior like regular MATLAB arrays.
##### 5 件のコメント表示非表示 4 件の古いコメント
Cedric Wannaz 2013 年 12 月 10 日
Hi Matt,
I agree with your claim, but 100 is not that much either. My point is that one shouldn't think "unless I perform millions of subsref/asgn, there is no need for a local copy", because the loss of efficiency can become significant as soon as more than a few "accesses" to properties are performed.
I have the issue with classes that are meant to become new types; the end user might not be able to "vectorize" his/her code, and might have to implement heavy loops. When I am not using local copies of properties which are used more than a few times, I can easily observe a factor two in execution time.

サインインしてコメントする。

Oliver Woodford 2013 年 11 月 20 日

REPMAT
Repmat is unnecessarily slow. Internally it produces an index array, which it then uses to create the output array. This is a gross waste of memory and performance. It is well known that repmat can be sped up significantly. Indeed, a much faster implementation can be found in the Lightspeed Toolbox. (I use this as standard, and thoroughly recommend it).
Given how often repmat is used (over 500 times in vanilla MATLAB functions alone), this function really is ripe for conversion to a fast builtin function.
Update: As of R2013b, REPMAT is a builtin function.
##### 6 件のコメント表示非表示 5 件の古いコメント
Oliver Woodford 2013 年 11 月 20 日
Copies are unappealing, but elementwise functions which make use of SSE instructions for multiple elements will run faster with the copy than calling the function once per element. The improvement of bsxfun I envisaged would do some copying internally to exploit this. But yes, if bsxfun were always faster then it should definitely replace repmat. However, given the amount of legacy code out there, it seems sensible to make repmat fast anyway. I'm glad TMW have obliged. Now bring on the improvement to bsxfun!

サインインしてコメントする。

Oliver Woodford 2013 年 11 月 20 日

IMFILTER with separable filters on multi-channel images.
This particular use case of imfilter is actually slower than using conv2. This is no longer the case in R2015a.
For example:
>> A = rand(1000, 1000, 3);
>> f = ones(7, 1);
>> f_ = f * f';
>> disp(timeit(@() imfilter(A, f_)))
0.1918
>> disp(timeit(@() imfiltsep(A, f, f)))
0.0526
where
function I = imfiltsep(I, fy, fx)
[H, W, C] = size(I);
sympadding = @(N, n) [floor(n/2)+1:-1:2 1:N N-1:-1:N-ceil(n/2-0.5)];
% For each channel separately
for c = C:-1:1
J = I(Y,X,c);
% Convolve
J = conv2(fy(:), fx(:), J, 'valid');
% Insert into array
I(:,:,c) = J;
end
end
Imfilter should really be at least as fast as conv2, if not faster, given that it uses Intel's IPP. There is no excuse for it being almost 4 times slower (in this particular case).
##### 3 件のコメント表示非表示 2 件の古いコメント
Oliver Woodford 2015 年 6 月 6 日
This is no longer the case in R2015a; imfilter is slightly faster than using conv2. I don't know from which release this improvement has been available though. I will investigate. But if somebody knows, please say.

サインインしてコメントする。

Matt J 2013 年 11 月 20 日

griddedInterpolant
seems under-optimized to me. I often need to do very large interpolation operations on 3D volumes, similar to the following. Professional customized software for my applications always seem to manage to do these kinds of operations much quicker than the 5.2 seconds shown.
N=400;
A=rand(N,N,N);
[x,y,z]=ndgrid(1:N);
f=@(u) u(:)+rand(size(u(:)));
x=f(x); y=f(y); z=f(z);
G=griddedInterpolant(A);
tic;
w=G(x,y,z);
toc;
%Elapsed time is 5.203962 seconds.
Furthermore, when I run the above, the Task Manager shows that my CPU is greatly under-used (only 21% at peak and only 3 of the 12 cores are significantly active).
##### 3 件のコメント表示非表示 2 件の古いコメント
Kelly Kearney 2013 年 11 月 21 日
No, I'm referring to data that definitely lies on a grid, but not necessarily a perfectly regular one. In my case, this is usually geographic data on a small scale (on the order of 1000km), defined on a regular latitude x longitude x depth grid. At this scale, any translation of the lat/lon coordinates (such as to meters, to match the typical depth unit) will result in a little bit of distortion from a perfectly orthogonal grid.
It seems to me that griddedInterpolant would be the better choice here, with neighbors and connectivity being determined by the organization of the input data. The triangulation built by scatteredInterpolant is not well-suited to datasets like this that are nearly-gridded... it can often return very weird values (for example, values well out of the input data range when using a nearest-neighbor interpolant, as the above example does).
Really, the best solution would be to stick with the lat/lon/depth grid but write a variation on griddedInterpolant that uses geographic distance rather than Euclidean. But I haven't gotten around to writing such a function yet...

サインインしてコメントする。

Walter Roberson 2013 年 11 月 21 日
This is a bit indirect, but:
There needs to be a way to flush an output buffer, including for serial ports and instrument control. Here, I am using "flush" in the sense of sending the data now instead of waiting for a buffer to fill up or for a device timeout. This is not the same sense of "flush" as in Instrument Control Toolbox's "flushoutput" routine, which aborts pending output and removes it from the queue.
The only way to guarantee the buffer is flushed is to use fclose if you open with A or A. Using a or w flushes the buffer after each write.
which is referring to file I/O. It is not completely clear to me that this applies to opening serial ports (or emulators thereof) by name, as that would fall under the fopen (serial) topic.
One particular place that this sort of flushing is needed is if one is speaking via a Serial over USB device. When data is sent to such a device, the data is not transmitted until the buffer is full or a timeout is reached; that timeout is 20 ms (max 50 cycles/second). USB drivers support a "push" request to send the data immediately, but MATLAB does not offer any method to request it. The Unix Way is for flush() or fflush() to take care of details like that... but those routines are not available in MATLAB. POSIX.1 defines that fseek() requires a write flush, and recommends fseek() to the same location (0 bytes relative to current position) in order to synchronize (such as to allow switching between read and write mode.) My testing appeared to indicate that using MATLAB's fseek() this behavior is not supported.
50 Hz maximum for serial interactions over USB is a substantial bottleneck these days.
##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Royi Avital 2013 年 11 月 21 日
filter
As published in File Exchange, simple loop unrolling is much faster than the current implementation. Also the GPU implementation isn't as good as expected.
randn
I'd be happy to see a faster random number generator.
##### 1 件のコメント表示非表示 なし
Oliver Woodford 2013 年 11 月 27 日
The question is roughly "what functions aren't as fast as they could be" rather than "... aren't as fast as we'd like them to be". In the case of randn is there any reason to believe it could be faster?

サインインしてコメントする。

Oliver Woodford 2013 年 11 月 21 日

Linear 2D interpolation for multi-channel images
A common computation in computer vision, and many other fields, is sampling of a multi-channel image at non-integer pixel locations, using linear interpolation. MATLAB has no reasonably fast way of doing this. I use this functionality everyday in my work, and it is often an algorithmic bottleneck.
To demonstrate, I have the following benchmark
function test_interp2
A = rand(1000, 1000, 5);
X = rand(1e4, 1) * 1000;
Y = rand(1e4, 1) * 1000;
T = [timeit(@() ojw_interp2(A, X, Y)) timeit(@() interp2_(A, X, Y)) timeit(@() gridinterp2(A, X, Y)) timeit(@() gridinterp2_(A, X, Y))];
disp(T / min(T));
end
function B = interp2_(A, X, Y)
for a = size(A, 3):-1:1
B(:,a) = interp2(A(:,:,a), X, Y);
end
end
function B = gridinterp2(A, X, Y)
F = griddedInterpolant(A);
B = F([reshape(repmat(Y, 1, 5), [], 1) reshape(repmat(X, 1, 5), [], 1) reshape(repmat(1:5, numel(X), 1), [], 1)]);
end
function B = gridinterp2_(A, X, Y)
for a = size(A, 3):-1:1
F = griddedInterpolant(A(:,:,a));
B(:,a) = F(Y, X);
end
end
the output of which is (on my PC)
1.0000 63.1709 12.9653 27.6083
This shows that ojw_interp2, which is my own C++ mex implementation (parallelized using OpenMP but not exploiting SSE instructions or IPP, so not especially optimized) is much faster than available MATLAB functionality (unless I'm missing another approach).
##### 4 件のコメント表示非表示 3 件の古いコメント
Oliver Woodford 2013 年 11 月 21 日
No, you need to construct the interpolant in the loop. I've added that example to the benchmark in the answer. You'll see that replicating the data is faster.

サインインしてコメントする。

Oliver Woodford 2013 年 11 月 21 日

TYPECAST
Typecast uses a deep copy rather than a shared data copy, as explained by James Tursa in his typecastx FEX submission. This makes it much slower than necessary for large arrays. On my system:
>> A = rand(1e6, 1);
>> disp(timeit(@() typecast(A, 'uint8')) / timeit(@() typecastx(A, 'uint8')))
284.0158
That is an amazing speed up! I don't use typecast often, but it has been a critical component in a couple of methods (both times the typecast data was large, and was not then updated, making the pre-emptive copy unnecessary), and to know it could easily be that much faster is frustrating.
Thanks to Daniel, Jan Simon and James Tursa for leading me to this.
Update: As of R2014b, TYPECAST no longer copies the data in memory, so is much faster.
##### 1 件のコメント表示非表示 なし
Oliver Woodford 2015 年 8 月 10 日
Quite a few of the issues raised here have been fixed. Could TMW be reading this question? :)

サインインしてコメントする。

Ilham Hardy 2015 年 4 月 13 日
datenum
and
cell2mat
##### 1 件のコメント表示非表示 なし
Oliver Woodford 2015 年 6 月 1 日
Is there any reason to believe these functions are slower than they could be?

サインインしてコメントする。

Oliver Woodford 2015 年 6 月 5 日
It needs a NOP function - a builtin function which does absolutely nothing, but extremely quickly.
In compiled languages like C++ people often place checks in their code, which are compiled out in Release builds, but left in for Debug builds, to find sources of errors more easily.
People sometimes also like to do this in MATLAB, for example as described here. However, the "compiled out" code (the checking function is replaced with a function which does nothing) still takes quite a long time to run.
Consider the following code:
function test()
%debug = @(varargin) disp(varargin{:});
debug = @nop;
c = 1;
for a = 1:1e6
c = c + 1;
debug(c);
end
end
function nop(varargin)
end
In R2015a the profiler outputs this:
The NOP function still takes around 20 times as long as a scalar addition. It would be great if it took 0s.
##### 7 件のコメント表示非表示 6 件の古いコメント
Walter Roberson 2015 年 9 月 10 日
What would be the timing if you replace the function debug with an array of length (1e6 + 1) ? That is it would be converted into an array reference whose value is to be thrown away; hypothetically the JIT might do better on that.

サインインしてコメントする。

Jan 2015 年 10 月 9 日

##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Oliver Woodford 2015 年 11 月 20 日
Matrix operations involving the transpose of a sparse matrix, especially J' * J and J' * K, where J is a very tall matrix. Constructing the transpose is costly in time, and also memory, in these cases. It would be much better to do the computation without explicitly doing the transpose.
##### 0 件のコメント表示非表示 -1 件の古いコメント

サインインしてコメントする。

Oliver Woodford 2016 年 9 月 18 日
MATLAB has no documented functions for reading JSON files, and the internal, undocumented method:
is slow. In fact, it is over 10x slower than my own mexed version of a C++ library for doing the same task.
Given the ubiquity of JSON nowadays, MATLAB could be doing a lot better.
##### 1 件のコメント表示非表示 なし
Steven Lord 2016 年 9 月 19 日
The Release Notes list webread (introduced in release R2014b) and jsondecode and jsonencode (both introduced in release R2016b.) Do they satisfy your needs for reading JSON files?

サインインしてコメントする。

Chad Greene 2016 年 9 月 18 日
The scatter function is incredibly slow for large datasets. I've had to switch to using Aslak Grinsted's fastscatter almost exclusively.
##### 2 件のコメント表示非表示 1 件の古いコメント
Chad Greene 2016 年 9 月 20 日
Oh, good to know! I haven't checked out R2016b yet.

サインインしてコメントする。

Hao Zhang 2018 年 4 月 18 日

Matrix indexing needs speeding up.

For a very simple example, if I run this:

```clear;
clc;
close all;
N1=100;
N2=100;
A=(ones(N1,N2,'single'));
C=(ones(N1,N2,'single'));
tic;
for i=1:1e4
%C(2:end,:)=C(2:end,:)-A(1:end-1,:);
C=C-A;
end
toc;
```

I got Elapsed time is 0.056711 seconds.

Instead if I run the following:

```clear;
clc;
close all;
N1=100;
N2=100;
A=(ones(N1,N2,'single'));
C=(ones(N1,N2,'single'));
tic;
for i=1:1e4
C(2:end,:)=C(2:end,:)-A(1:end-1,:);
%C=C-A;
end
toc;
```

I got: Elapsed time is 0.316735 seconds.

That is to say the most of the time Matlab is just doing the matrix indexing, Is there any way to improve this or avoid the indexing but get the same result? This could make my code almost 10 times faster!

##### 11 件のコメント表示非表示 10 件の古いコメント
James Tursa 2018 年 4 月 19 日

サインインしてコメントする。

Bruno Luong 2018 年 4 月 18 日

persistent statement

Not sure the reason (internal data hashing?) , but it is slow.

サインインしてコメントする。

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by