Re: Speeding Up gnuplot Interface with Binary Data

[John W. Eaton]

On 15-Oct-2008, Daniel J Sebald wrote:

| Dmitri A. Sergatskov wrote:
| > On Tue, Oct 14, 2008 at 11:37 PM, John W. Eaton <address@hidden> wrote:
| > 
| > 
| >>I think it would be better to use
| >>
| >> sprintf ("record=%d", numel (obj.xdata));
| >>
| >>instead.
| >>
| > 
| > 
| > Both works for me. Just an observation: running
| > tic; plot(rand(1000)); toc
| > 
| > takes 2 seconds with 3.0.2 and 12 with 3.1.51+
| > 
| > Of course, the gnuplot's time is the other way around,
| > so we loosing time on formatting data into binary format and
| > than win some back during the parsing.
| 
| Huh?  Binary should be faster on both sides.  fwrite() should be faster than 
fprint(), fread() faster than fscanf(), generally speaking.  How long ago is 
3.0.2?  What were the changes between those two versions?

he fwrite function is not fully optimized, so it makes one system
call for each matrix element written to the output stream.  It works
this way so that type and format conversions can be handled easily,
without needing to allocate additional memory.  It would be better to
use a blocked algorithm, to minimize the number of writes and still
avoid memory usage problems.  But doing that is somewhat more complex
and it was worth the time to me when I last worked on that part of the
code.

However, I'm still surprised that the difference is so large.  On my
system with 3.1.51+, both cases (before and after the patch for binary
writes) the tic/toc time for the above plot is about the same (around
35 seconds in both cases, but that is with a copy of Octave built with
compiler optimization disabled), but gnuplot reads the data and
renders the plot much faster.  3.0.1 on the same sysetem only takes
about 2.5 seconds to send the plot down the pipe.  There have been
many changes in the plotting code since 3.0.x, but I don't think the
fwrite change is to blame.

jwe