Re: more graphics changes.

[Daniel J Sebald]

John W. Eaton wrote:
> On 14-Mar-2007, Daniel J Sebald wrote:
>
> | I definitely see a speed up.  But there is still some lag.  Something like 
> | "image" with the default image should be processed by gnuplot with little 
> | effort.  With the latest, there is still a one to two second delay on my machine.
> | 
> | I recall when writing some of the image.m code and testing with various size 
> | images that the test image would plot almost immediately.  Has there been a 
> | change in the pipe that causes it to pause when the buffer is full?
>
> No change that I know of.  The pipe to gnuplot is still opened in
> drawnow.m and everything is written to that pipe in __go_draw_figure__.m
> and __go_draw_axes__.m, which were just renamed from the
> __uiobject_draw_figure__.m and __uiobject_draw_axes__.m files with a
> few small changes to adapt to other name changes.  But nothing that
> should have affected the way data is written to the pipe.


I've searched for time sinks and I guess this boils down to the speed of 
interpretation.  In some ways it seems a little high cpu consumption, but I 
guess that is just the way it is.  For example, let's look at some M files to 
illustrate.

In __go_draw_axes__.m is this line

[img_fid, img_fname] = mkstemp (fullfile (P_tmpdir, "gpimageXXXXXX"), 1);

Built in functions are fast.  Consider:

octave:172> tt=cputime();  P_tmpdir(); cputime()-tt
ans =  0.0010000

Very short.  Now using the M-file fullfile() things slow a bit:

octave:176> tt=cputime();  fullfile (P_tmpdir, "gpimageXXXXXX"); cputime()-tt 
ans =  0.13198

There's not a lot inside fullfile(), but I guess the file has to be read in, 
parsed, organized, etc.


I do find something odd about cputime().  Consider the following:

octave:204> [tt,tu,ts]=cputime(); image; [tt2,tu2,ts2]=cputime(); 
[tt2,tu2,ts2]-[tt,tu,ts]
ans =

   0.55092   0.44993   0.10098


You'd think that it has taken 0.5 s cputime to send an image to gnuplot.  How 
long would that translate to in actual time?  I don't know, 3/4 second?  Unless 
the system is really overloaded.  But what I'm observing takes clearly more than 
3/4 s, maybe two seconds.  The strange result is that along with the above 
output, I've put

tx=cputime();
    have_newer_gnuplot = compare_versions (__gnuplot_version__ (), "4.0", ">");
cputime()-tx

inside __go_draw_axes__() because I suspected that version test as being a slow 
instruction.  This instruction is run as part of the above image() plot and the 
result is

ans =  0.84987

That is surprising.  Not only is it quite long, it is longer than any of the 
above time differentials.  I'm lead to believe there might be a bug in cputime() 
if I'm reading the documentation correctly.


So, I suspect a lot of the time discrepancy I feel when watching how long it 
takes to draw the image is probably part of the compare_versions().  Let me test 
that from the command line:

octave:206> [tt,tu,ts]=cputime(); compare_versions (__gnuplot_version__ (), 
"4.0", ">"); [tt2,tu2,ts2]=cputime(); [tt2,tu2,ts2]-[tt,tu,ts]
ans =

   0.88486   0.72789   0.15698

OK, well this would suggest one should use a good scripting strategy that avoids 
function calls as much as possible.  There is no need to keep checking whether 
one has a newer gnuplot version after the first time.  So, I'd think something like

    global __got_gnuplot_version__ = 0;
    global have_newer_gnuplot;
tx=cputime();
    if (! __got_gnuplot_version__)
      have_newer_gnuplot = compare_versions (__gnuplot_version__ (), "4.0", 
">");
      __got_gnuplot_version__ = 1;
    endif
cputime()-tx

would save time, and in fact it does noticeably.

Dan