[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slowing scatter down for the sake of Matlab compatibility
From: |
Ben Abbott |
Subject: |
Re: Slowing scatter down for the sake of Matlab compatibility |
Date: |
Sun, 04 Dec 2011 19:29:49 -0500 |
On Dec 4, 2011, at 6:25 PM, Ben Abbott wrote:
> On Dec 4, 2011, at 5:28 PM, Jordi Gutiérrez Hermoso wrote:
>
>> 2011/12/4 Robert T. Short <address@hidden>:
>>> Jordi Gutiérrez Hermoso wrote:
>>>>
>>>> Re this bug:
>>>>
>>>> https://savannah.gnu.org/bugs/?34936
>>>>
>>>> It looks to me like it boils down to keeping Matlab compatibility and
>>>> making a patch object per dot. If we do that, then we really ought to
>>>> figure out a way to optimise __go_patch__ for each possible backend,
>>>> because it's a tremendous slowdown to do this for as little as 1000
>>>> points.
>>>
>>> Jordi, we went through this a long time ago.
>>
>> It looks like the result of that discussion resulted in a lot of
>> brokenness. The scatter code doesn't work very well for more than 100
>> points and has a lot more complexity than it should, I think.
>>
>>> I think the conclusion was that MATLAB does the patch object for
>>> each dot only up to some number of dots (100 is the number I
>>> recall).
>>
>> Oh great, this almost what the current Octave code does too.
>>
>> What does it for more than 100 points? How many patch objects?
>>
>> - Jordi G. H.
>
> 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
>
> The result was ...
>
> numel(x) = 1, numel(hg) = 1, numel(hp) = 1
> Time to render = 1.141709 seconds
> numel(x) = 10, numel(hg) = 1, numel(hp) = 10
> Time to render = 0.007783 seconds
> numel(x) = 100, numel(hg) = 1, numel(hp) = 100
> Time to render = 0.026855 seconds
> numel(x) = 1000, numel(hg) = 1, numel(hp) = 1000
> Time to render = 0.215966 seconds
> numel(x) = 10000, numel(hg) = 1, numel(hp) = 10000
> Time to render = 2.079570 seconds
> numel(x) = 100000, numel(hg) = 1, numel(hp) = 100000
> Time to render = 20.737153 seconds
>
> 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?
>
> Ben
On the IRC, John asked about the example below.
n=1000; h=scatter(rand(n,1),rand(n,1)); k=get(h,'children'); numel(k)
ans =
1
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
Ben
Slowing scatter down for the sake of Matlab compatibility, John W. Eaton, 2011/12/04