Should table Indexing be Faster?

Example code.

t = combinations(0:10,0:10,0:10,0:10);

tic
for ii = 1:10
    for jj = 1:height(t)
        u = t{jj,:};
    end
end
toc

Elapsed time is 18.111169 seconds.

tic
tcell = table2cell(t);
for ii = 1:10
    for jj = 1:height(tcell)
        u = [tcell{jj,:}];
    end
end
toc

Elapsed time is 0.179943 seconds.

tic
tarr = table2array(t);
for ii = 1:10
    for jj = 1:height(tarr)
        u = tarr(jj,:);
    end
end
toc

Elapsed time is 0.017899 seconds.

Any ideas why indexing into a table to extract data is so slow?

[Walter Roberson]

By the way: we held a discussion of table indexing across rows, about two-ish years ago. I know that I contributed, and I seem to remember that Steven Lord contributed. The thread revived briefly a couple of months ago. Unfortunately I do not seem to be able to locate it at the moment.

[Paul]

No change in 2025a

t = combinations(0:10,0:10,0:10,0:10);
tic
for ii = 1:10
    for jj = 1:height(t)
        u = t{jj,:};
    end
end
toc

Elapsed time is 18.246674 seconds.

[Paul]

Looks like there has been an improvement since 2025a (but still pretty slow compared to cell and and regular arrays, but I didn't see anything on this topic in the release notes.

I wonnder if this is as good as it will get and how the improvement was obtained.

version

ans = '26.1.0.3203278 (R2026a)'

t = combinations(0:10,0:10,0:10,0:10);
tic
for ii = 1:10
    for jj = 1:height(t)
        u = t{jj,:};
    end
end
toc

Elapsed time is 8.317014 seconds.

[Matt J]

Re-running the test from 09/16/2024,

T = combinations(1:100,1:100,1:40,1:40);
t=T(1,:);

timeit(@() t{1,:})

ans = 9.7704e-05

timeit(@() T{1,:})

ans = 0.2880

Doesn't seem like a significant improvement.

[Paul]

@Matt J

Any idea why your test didn't change and mine improved by a factor of ~2 ? I'm still back on 2024a and can't check if any changes were made to @tabular/braceReference, which you suspected was the culprit.

[Matt J]

@Paul No, I really couldn't say where the factor of 2 in your test is from. Maybe some sort of JIT improvement? Whatever was changed, though, it clearly wasn't directed at the root issue in @tabular/braceReference. It's just not that hard to fix.

Answer 1

[Matt J]

I haven't profiled it, but I would bet that the following line, from @tabular/braceReference

b = t.extractData(varIndices);

is bottlenecking the row extraction operations. Effectively, this runs table2array(t) on the entire table t every time a braceReferencing operation is done.

That probably should be done differently, since as a result, the time for even the smallest row-extraction operation is a very strong function of the size of the table, see example below:

T = combinations(1:100,1:100,1:40,1:40);
t=T(1,:);

timeit(@() t{1,:})

ans = 1.4134e-04

timeit(@() T{1,:})

ans = 0.2923

[Matt J]

I have now reported this to Tech Support.

[Paul]

Thanks for your inputs and discussion. If you don't mind, please post back here with their response.

[Paul]

If I understand correctly, then column extraction should also be a function of the size of the table (assuming table2array inside extractData works the same for a wide table as it does for a tall table). But it isn't.

T = combinations(1:100,1:100,1:40,1:40);
T = array2table(table2array(T).');
size(T)

ans = 1×2

4 16000000

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

t=T(:,1);
timeit(@() t{:,1})

ans = 3.6526e-05

timeit(@() T{:,1})

ans = 2.8859e-05

Does braceReference() work differently when extracting columns?

[Matt J]

Yes, once again if we look at the line,

b = t.extractData(varIndices);

we see that extractData() uses varIndices. This is used to discard columns that aren't being referenced, and does so before any data copying is done. This greatly reduces the overhead. It ought to be doing the same with the rows, but it isn't.

[Matt J]

From Tech Support:

Thank you for identifying a performance slowdown when extracting rows from a table. My colleagues are aware of the issue and are working on a fix. In the meantime, a workaround is to use parenthesis subscripting.

For example, currently you are extracting rows using the following syntax. Instead, extract rows using parentheses.

T = combinations(1:100,1:100,1:40,1:40);
t = T(1,:); 

When I compared the elapsed time for both these syntaxes, the suggested workaround of parentheses was significantly faster than the original.

%Original example
tic, for i = 1:100, t1 = t{1,:}; end, toc 
Elapsed time is 0.005140 seconds.  

tic, for i = 1:100, t1 = T{1,:}; end; toc 
Elapsed time is 4.458811 seconds.  


% Workaround 
tic, for i = 1:100, t1 = t(1,:); t1 = t1.Variables; end, toc  
Elapsed time is 0.006460 seconds.  

tic, for i = 1:100, t1 = T(1,:); t1 = t1.Variables; end; toc 
Elapsed time is 0.005319 seconds. 

[Paul]

Just want to point out that creating the temporary variable (t1 in this case) isn't necessary if the result is to be used directly, like as an input to a function

T = combinations(1:100,1:100,1:40,1:40);
T(1,:).Variables

ans = 1×4

1 1 1 1

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

Also, perhaps MathWorks should consider a near term update to use this exact workaround in rowfun when it's called with SeparateInputs=false