Re: Slowing scatter down for the sake of Matlab compatibility

[Jordi Gutiérrez Hermoso]

2011/12/4 Ben Abbott <address@hidden>:
> On Dec 4, 2011, at 6:25 PM, Ben Abbott wrote:
>> I tried the script below on ML R2011b.
>>
>> for p = 0:5
>>  tic
>>  n = 10^p;
>>  x = rand (n,1);
>>  y = rand (n,1);
>>  colours = [ ones(n,1) zeros(n,1) zeros(n,1) ];
>>  colours(1,:) = [0 0 1];  % different color for first element
>>  hg = scatter (x, y, 15, colours);
>>  hp = findall (hg, 'type', 'patch');
>>  fprintf ('numel(x) = %d, numel(hg) = %d, numel(hp) = %d\n', numel (x), 
>> numel (hg), numel (hp))
>>  fprintf ('Time to render = %f seconds\n', toc)
>> end
[snip]
>> It appears that ML consistently creates one patch for each point.
>>
>> Perhaps an option can be added to scatter() to skip ML
>> compatibility? There is already a "filled" option. Can a "collect"
>> option be added? Then the patches with consistent size, and color
>> may be collected into a single patch?

Sigh... It's not much use if it's not the default behaviour...

> Using a modified test script
>
> for p = 0:5
>  tic
>  n = 10^p;
>  x = rand (n,1);
>  y = rand (n,1);
>  hg = scatter (x, y, 15);
>  hp = findall (hg, 'type', 'patch');
>  fprintf ('numel(x) = %d, numel(hg) = %d, numel(hp) = %d\n', numel (x), numel 
> (hg), numel (hp))
>  fprintf ('Time to render = %f seconds\n', toc)
> end
>
> numel(x) = 1, numel(hg) = 1, numel(hp) = 1
> Time to render = 0.007314 seconds
> numel(x) = 10, numel(hg) = 1, numel(hp) = 10
> Time to render = 0.009084 seconds
> numel(x) = 100, numel(hg) = 1, numel(hp) = 100
> Time to render = 0.034167 seconds
> numel(x) = 1000, numel(hg) = 1, numel(hp) = 1
> Time to render = 0.017748 seconds
> numel(x) = 10000, numel(hg) = 1, numel(hp) = 1
> Time to render = 0.099743 seconds
> numel(x) = 100000, numel(hg) = 1, numel(hp) = 1
> Time to render = 0.964281 seconds

Okay, so is this the behaviour we must mimic? Create one patch object
per dot unless there is no colour parameter passed and there are more
than 100 dots?

Is there any way to speed this up? What's the big slowdown about
calling __go_patch__ object thousands of times? Does this produce a
redraw of the graphics every time? Is there a way to first record all
the objects and only draw at the end?

- Jordi G. H.