Nested Functions vs Object-Oriented Programming: k-D Tree example and relative performance

10 次查看（过去 30 天）
Jacob Lynch August
Jacob Lynch August 2020-8-13
回答： Olaf Constantin Schmidtmann 2022-5-3
My colleagues tend to criticize my use of nested functions in MATLAB, likening that to the professional no-no of modifying global variables. To placate those peers, I'll recode those methods that use nested functions into a handle-based object-oriented methods. Now, they accept that the current properties are accessible to the object's methods.
However, I have a specific instance where the nested functions implementation outperforms the handle-based object-oriented programming style: k-D Trees.
Using nested subfunctions. https://www.mathworks.com/matlabcentral/fileexchange/79101-ikdtree
Using subclass of handle. https://www.mathworks.com/matlabcentral/fileexchange/79104-kdtree
Here is the benchmark code run from the command window.
pdat = randn(130001,3); % position data
tic;a_tree = kDTree(pdat); disp(toc) % 9.0822 seconds
tic;i_tree = ikdtree(pdat);disp(toc) % 1.0869 seconds
I'm seeking insights into what is causing these performance differences.

请先登录，再回答此问题。

采纳的回答

per isakson
per isakson 2020-8-14
编辑：per isakson 2020-8-14
On my R2018b,Win10 the diffence is even bigger
% 18.585, 0.79143
% 18.937, 0.75923
The profiling result of get_root_index shows
that assigning values to the properties, LeftIndices and RightIndices, takes nearly all the time.
It's a known fact that assigning values to properties is slow in Matlab. See Is MATLAB OOP slow or am I doing something wrong? and Numerical operations are slow on class properties versus in workspace.
The execution engine (/JIT) is The Mathworks' trade secret.
  2 个评论
Jacob Lynch August
Jacob Lynch August 2020-8-14
编辑：Jacob Lynch August 2020-8-14
That is surprising! I would not have expected the MATLAB JIT compiler to incur such penalties for OOP. My code used to be entirely functional (not in the rigorous FP sense, just that it only used functions), but that code quickly became overcooked spaghetti: broken and unmanageable.
The performance gains I reaped when migrating to class-centric MATLAB programming (at the suggestion of my more seasoned Software Engineering colleagues) seem to be more the resulf of implementing better functions rather than better data structures.

请先登录，再进行评论。

更多回答（1 个）

Olaf Constantin Schmidtmann
Even in R2022a, the performance gap between these two is quite huge on my machine (MACI64). This contradicted my results of Andrew Janke’s matlab-bench and I wondered why.
Without digging too deep into the functions themselves, I found that the OOP version (subclass of handle) uses property validation, which is expensive at this point. Hence, the comparison is a bit unfair. ;)
If you remove the validation (lines 11-14), like so:
properties (SetAccess = protected)
LeftIndices %(:, 1)
RightIndices %(:, 1)
end
… the tables turned on my machine; the OOP version was even a bit faster:
OOP (kDTree, original): Elapsed time is 5.630146 seconds.
OOP (kDTree, no validation of indices): Elapsed time is 0.579906 seconds.
Nested (ikdtree): Elapsed time is 0.641538 seconds.
You may add a dependent variable for subclasses to keep the validation. Also you might compare a custom validation in the nested version…
Btw, I do not believe, that OOP is a silver bullet, but there is clearly more to the decision than performance issues.

类别

在 Help Center 和 File Exchange 中查找有关 Whos 的更多信息

标签

产品


版本

R2019a

Community Treasure Hunt

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

Start Hunting!

Translated by