# Numerical operations are slow on class properties versus in workspace

36 views (last 30 days)
Daniel Plotnick on 22 Jun 2020
Edited: per isakson on 26 Jun 2020
Hello,
I ran into this behavior I don't really understand: simple numerical operations are order 10x+ slower on class properties than when performed in the workspace.
As an example, I will create a circular index that I want to increment by 1.
N = 2^16; % Number of times to increment
M = 2^8; % What is our wrap point
I = 0; % Initialize our index
t = tic;
clc
disp("Incrementing in workspace");
for n = 1:N
I = mod(I+1,M); % Increment, with wrapping
end
fprintf("%2.0f kOps/second\n",N/toc(t)/1000); % 1000s of operations/second
Great, I am getting ~ 45,000 kOps/second.
Now, instead I will do this all in a class:
classdef speedTestClass < handle
properties
I = 0;
M
end
methods
function increment(obj)
obj.I = mod(obj.I + 1,obj.M); % Increment, with wrapping
end
end
end
And then run it
ob = speedTestClass; % Make the object
ob.M = M; % Set the wrap point
disp("Incrementing in class");
t = tic;
for n = 1:N
ob.increment % Increment, with wrapping
end
fprintf("%2.0f kOps/second\n",N/toc(t)/1000);
Where I get 2400 kOps/second. A slowdown factor of 20x. Yikes.
So, is there a way to more efficiently perform simple operations on class properties? Is there some MEX magic working behind the scenes, and so I would need to MEX my classes?
I couldn't think of a simpler example than this basic index container; I could understand a factor of 2x speed loss, but 20x is huge, and it only gets worse when the computation is more involved and involves multiple methods/properties of the class.
I'll note that on a lark, I actually compiled this into an exe and ran it - the workspace version dropped to the speed of the class based one! Oh no.
Cheers all,
-Dan
Daniel Plotnick on 23 Jun 2020
@per isakson - Wow, this is an extremely thorough analysis. I think the gist is
1. Yes, OOP is way slower than functional coding
2. No, I'm not doing something wrong and there is no current way around these speed issues.
3. It is unclear exactly what the bottleneck is, since closed source, but each type of access to a custom class object is going to incur some penalty.
@James Tursa - Thanks for the analysis. I continued working on it, and had planned to post the code/results here, but the Stackoverflow link has a set of benchmark code available that goes way further than I had considered.
I will note, that in the case of the buffers, the fastest solution I found was to only store the pointers and index retrieving methods for the FIFO/LIFO cases in a class; the actual buffer stays inside of the functional workspace. This reduces some of the class-based elegence I had hoped for, but bought me back a considerable speed factor.
pt = myPointer(N);
disp("Using a pointer")
t = tic;
buf = zeros(N,1);
for n = 1:N
buf(pt.v + 1) = n;
pt.increment;
end
fprintf("%2.0f kOps/second\n",N/toc(t)/1000);
with the pointer class
classdef myPointer < handle
properties
v = 0;
n
end
methods
function obj = myPointer(n)
obj.n = n;
end
function increment(obj)
obj.v = mod(obj.v + 1,obj.n);
end
end
end

Matt J on 22 Jun 2020
Edited: Matt J on 22 Jun 2020
It is the repeated M-coded function calls that are slowing you down. Implement the whole loop in a single function call:
function increment(obj,N)
M=obj.M;
I=obj.I;
for n = 1:N
I = mod(I+1,M); % Increment, with wrapping
end
obj.I=I;
end
Matt J on 23 Jun 2020
Edited: Matt J on 23 Jun 2020
See my updated analysis above,
I now think you are seeing overhead from classdef's specifically, though not just from property access. I think the bottom line is one just needs to try to put loops inside functions and not the other way around. and/or to write loops that do lots of computation per iteration (esp. with vectorized commands) instead of really small and quick tasks. These were always best practices in writing efficient Matlab code, although I have to admit, I thought TMW had mananged to better optimize class operations over the years than what we're seeing now.