Fwd: nobody bothered by the slowness of contours in gnuplot/fltk??

[Ben Abbott]

Begin forwarded message:

> From: kloof <address@hidden>
> Date: October 11, 2010 8:56:49 AM PDT
> To: address@hidden
> Subject: Re: nobody bothered by the slowness of contours in gnuplot/fltk??
> 
> 
> Dear Martin,
> 
> I've put the z(x,y) data (here x=280 y=1024) and the 'script' on the
> following page.
> This example takes about 1.5 minutes, before the plot appears.
> 
> http://homepage.tudelft.nl/8t03d/
> 
> 
> Thanks for the reply and your efforts!
> 
> kloof
> 
> ps. using plplot a contour plot of this data pops up in 1 second.

I'm also running MacOS X

        octave:1> backend fltk
        octave:2> load octave_binary_data.txt
        octave:3> tic (); contour (tof, hoek, I); toc ()
        Elapsed time is 114.879 seconds.
        octave:4> whos tof hoek I

        Variables in the current scope:

          Attr Name        Size                     Bytes  Class
          ==== ====        ====                     =====  ===== 
               tof         1x1024                    8192  double
               hoek        1x280                     2240  double
               I         280x1024                 2293760  double

However, with a simple example ...

        octave:5> x = linspace (-3, 3, 1024);
        octave:6> y = linspace (-3, 3, 280);
        octave:7> z = peaks (x, y);
        octave:8> tic (); contour (x, y, z); toc ()
        Elapsed time is 0.329376 seconds.

        octave:9> whos x y z
        Variables in the current scope:

          Attr Name        Size                     Bytes  Class
          ==== ====        ====                     =====  ===== 
               x           1x1024                    8192  double
               y           1x280                     2240  double
               z         280x1024                 2293760  double


The slow-down is proportional to the number of patches (3297 vs 16 for the 
above) created in by the subfunction add_patch_children() which is in 
__contour__.m.

If the creation of the patches (lines 336:366) could be vectorized the slow 
down would be substantially reduced.

I'll file a bug report.

Ben