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 18:25:27 -0500

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



reply via email to

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