Why does specifying the size of a class property slow down writes?

I am trying to buffer some data in an object, and I noticed that specifying the size of the buffer in the class property affects the runtime performance. It doesn't make a lot of sense to me why performance would improve when the size of the data is not specified. I am running Matlab 2024b.

Here is a small example that illustrates how specifying the data size slows down the runtime performance by a factor of 5-10x. The array buffering is used to baseline the test.

classdef MyBufferFast < handle
    properties
        % No size property set.
        buffer
    end

    methods
        function [obj] = MyBufferFast()
            obj.buffer = zeros(10, 1);
        end
        
        function [] = BufferData(obj, data)
            % Slicing here to replicate middle-of-buffer insertion.
            obj.buffer(1:10) = data;
        end
    end
end

classdef MyBufferSlow < handle
    properties
        % Why does setting the size property here slow it down?
        buffer(10, 1) double
    end

    methods
        function [obj] = MyBufferSlow()
            obj.buffer = zeros(10, 1);
        end
        
        function [] = BufferData(obj, data)
            % Slicing here to replicate middle-of-buffer insertion.
            obj.buffer(1:10) = data;
        end
    end
end

%% Setup
clc; clear all; close all;

rng(1);
num_data = 100000;
data_to_buffer = randn(10, num_data);

%% Buffer with array
array_buffer = zeros(10, 1);
tic;
for idx = 1:num_data
    array_buffer(1:10) = data_to_buffer(:, idx);
end
array_time = toc;

%% Buffer with fast object
my_buffer_fast = MyBufferFast();
tic;
for idx = 1:num_data
    my_buffer_fast.BufferData(data_to_buffer(:, idx));
end
fast_buffer_time = toc;

%% Buffer with slow object
my_buffer_slow = MyBufferSlow();
tic;
for idx = 1:num_data
    my_buffer_slow.BufferData(data_to_buffer(:, idx));
end
slow_buffer_time = toc;

%% Report
disp(array_time);
disp(fast_buffer_time);
disp(slow_buffer_time);

% Times
% array_time:       0.0546
% fast_buffer_time: 0.0806
% slow_buffer_time: 0.5379

Answer 1

[Matt J]

The property validation specifications have to be processed every time you make an assignment to the buffer property. This takes extra time as compared to MyBufferFast, which does no property validation. However, it is worth noting that most of the extra time your current code incurs comes from doing,

obj.buffer(1:10) = data;

instead of simply,

obj.buffer = data;

With the latter, you will see that the time differences are not quite so large. On my machine,

0.0037

0.0098

0.0259

When you make an indexed assingment into a class property with validators, the validators have to check that your indexing operation doesn't change the size of the property. For example, in MyBufferFast, this operation would be perfectly legal,

obj.buffer(2:11)=data;

whereas MyBufferSlow needs to go through the effort of intercepting it and throwing an error message, because it lengthens the buffer beyond its valid size.

[Tucker]

Thanks for the input, Matt.

Regarding the indexing operation

obj.buffer(1:10) = data;

The indexing here is intended to reproduce the effects/slowdown of a middle-of-buffer insertion. In my problem, the buffer is much larger than the data, so the data must be copied in. In reality, the code would look more like

obj.buffer(start_idx:end_idx) = data;

If the indexing operation is skipped like with

obj.buffer = data;

then you're right and it does run much faster (I'm assuming because it's not copying data, rather copying a reference/pointer), but it's not quite reproducing the problem I have.

It makes sense that a slowdown will be incurred because of data size checks, but I suppose I'm surprised at the magnitude of the slowdown. For example, if I change MyBufferFast to do a size assertion check before assignment, the runtime trends are about the same:

function [] = BufferData(obj, data)
    assert(10 == numel(data));
    % Slicing here to replicate middle-of-buffer insertion.
    obj.buffer(1:10) = data;
end

Runtimes:
   0.0742
   0.0938
   0.8584

Happy to accept your answer that it's simply due to a slow size check if there are no other comments.

[Matt J]

but it's not quite reproducing the problem I have.

It's not reproducing the problem that you have, but it does serve to show that the size validation by itself isn't solely responsible for the slowdown. The size validation still has to be done even when the assignment is non-indexed.

For example, if I change MyBufferFast to do a size assertion check before assignment, the runtime trends are about the same:

Naturally. Adding an assertion check only adds processing. It doesn't subtract from it any way.

[Kyle]

@Tucker

You are very astute to notice that adding the size assertion does not slow the code down as much as adding the size property validation.

This is because in the 23b release, performance of dot indexing into properties was greatly improved. However, this improvement is less effective for properties with validation defined. From the Release Notes:

"Reading and writing class property values shows improved performance. The largest gains in performance are for accessing properties that do not use validation or get and set methods."

If this part of your code needs the improved performance, my suggestion would be to verify the values manually the way you do in your code example, rather than using property validation to do so.

[Tucker]

Hi Kyle,

Thanks for validating my observation and directing me to the release notes. It's good to know that there is a solution that is both performant and safe/documenting (no property validation + size assertion).

Perhaps the property validation performance will be improved in the future --- I'll be scanning the patch notes.

Tucker