octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]