Numerical operations are slow on class properties versus in workspace

49 次查看(过去 30 天)
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
  4 个评论
Daniel Plotnick
Daniel Plotnick 2020-6-23
@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

请先登录,再进行评论。

回答(1 个)

Matt J
Matt J 2020-6-22
编辑:Matt J 2020-6-22
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
  4 个评论
Daniel Plotnick
Daniel Plotnick 2020-6-23
编辑:per isakson 2020-6-26
Thanks! After your initial answer, I spent some time playing with the internal structure of the class. I intentionally broke out the the increment method from the wrap/mod method. I suffered an additional 2x penalty for going into a seperate method, so it seems to me that I will suffer going into methods the same way I do going into individual m-files.
A lot of this practical excercise is to try to understand my speed penalties when taking advantage of classes and OOP versus straight function based algorithms. There are huge advantages to OOP and design pattern based coding...but at least in Matlab, based on your and Tursa's answers, there will be considerable speed penalties as a consequence of striving for the encapsulation and code maintenance advantages of OOP.
Based on Tursa's comments, it sounds like carefully MEXing the classes won't actually buy me anything. While Matlab is great for prototyping, if I want a fully class based code with high speed, I may need to go for refactoring my code into another language.
I was hoping someone had a workaround; Matlab is my go-to.
Do you know if there is any documentation on the performance penalties with going into m-files? I can't tell if it is memory access (like Tursa suggested would be an issue with MEX), or JIT, or what that causes this speed loss.
Matt J
Matt J 2020-6-23
编辑:Matt J 2020-6-23
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.

请先登录,再进行评论。

类别

Help CenterFile Exchange 中查找有关 Loops and Conditional Statements 的更多信息

Community Treasure Hunt

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

Start Hunting!

Translated by