Re: Speeding Up gnuplot Interface with Binary Data

[John W. Eaton]

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

| John W. Eaton wrote:
| > On  7-Oct-2008, Daniel J Sebald wrote:
| > 
| > | John W. Eaton wrote:
| > | > On  7-Oct-2008, Daniel J Sebald wrote:
| > | > 
| > | > | John,
| > | > | 
| > | > | Attached is a patch using gnuplot's binary data input feature rather 
than ASCII data fifteen characters wide.  It does appear to speed up drawing a 
fair amount.  Less data is transmitted through the pipe, gnuplot doesn't have 
to input data as formated, and as I see it there is no need for handling NaN in 
a special way (it is just another value in IEEE format).
| > | > | 
| > | > | Let me know what you think.
| > | > 
| > | > This patch fails to apply cleanly to the current Octave sources.
| > | 
| > | Sorry.  I'm out of step with Mercurial.  Give this patch a try...
| > 
| > OK, this applies cleanly to my sources.
| > 
| > | +    fwrite (plot_stream, data, "float32");
| > 
| > Why float32?  That breaks things like
| > 
| >   plot ([1, 2], [3, 4]*1e100)
| > 
| > which used to work properly.  I think we should be sending double
| > precision data.
| 
| OK, I replaced the float32 in the previous patch with float64 in the proper 
places.

Thanks.

| (Is image and palette data going to need double precision as well?)

Can image or palette data exceed the range of float32?  Does the extra
precision matter?  If so, then yes we should use float64 instead.

| Can you notice a considerable speedup on your machine?  I have a fairly old 
machine so the change is obvious.

Yes, it seems about three times faster.

I applied the changeset.

Thanks,

jwe