Re: slow drawing with large images

[Daniel J S. <dan...@ie...>]

Bastian Maerkisch wrote:
> When drawing large images (binary and ascii) gnuplot is veeeery
> slow on my (windows) machine. E.g. with an image (RGB) of 1024*256
> pixels it takes about >5.5s to output on any terminal.
> 
> Profiling reveals that gnuplot spends >75% of it's time in
> gp_realloc()  <--  cp_extend() <--  get_data().
> 
> The crucial point is that the maximum increase of the points[]
> array is limited to 1000. Changing line 411 in plot2d.c
> 
> - cp_extend(current_plot, i + (i < 1000 ? i : 1000));
> + cp_extend(current_plot, i + i);
> 
> eliminates that problem, but uses exceedingly large amounts
> of memory.
> 
> Can anybody confirm this behaviour on non-windows machines?
> Or is this a problem of gp_realloc() on Windows?

In linux, even running through Octave, a 1024*256 image takes about .75 sec on a five year old pentium 3 (about 1 GHz, I forget memory speed).

I agree the linear expension rule is bad.  (In fact, in some cases with image one should be able to make a reasonable guess about the final number of points required.)

Why your system is so slow though, not sure?  With the 1000 rule and 1024*256 image, that means you'd execute cp_extend roughly 250 times.  (Not good.)  In that routine I see a TRACE_ALLOC() command which I'm sure is deactivated in my compilation.  Perhaps if you have that turned on by default, that's where the slowdown comes from.

Dan