Re: gnuplot slow on BIG files

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 08 June 2005 09:47 pm, HBB wrote:

I assume Robert benchmarked atof because that's what is currently
in the source code as a compile-time alternative.  But for a real
change-over in the default code I think we would need to go with
strtod instead.

> Ethan Merritt wrote:
> >
> > I think I'll remove that OSK chunk altogether,
>
> Please don't.  It's quite harmless as it is --- it'll only be used on
> one platform, and you would risk breaking that platform completely by
> doing this.

I don't think it's likely to break anything. The problem is in the %n 
format, which we can do without by using strtod instead.
But yeah, it's only a few lines of code.

> More to the point, atof has *no* error handling capabilities,
> which I don't believe to be a good idea in this case.

There is no error checking in the current code either, unless you
mean the count returned by sscanf. For true error checking we would
need strtod, unless I've overlooked some entirely different method.

> sscanf() and its %n format are used for a reason.

But %n is non-portable, as documented by the OSK comment and also
by the linux man pages.  So if Robert can benchmark the performance of
strtod as no worse than the current default code, then replacing both
paths with a strtod call may solve all these issues at one stroke.

I'm also curious about that convoluted series of tests added by
Corey Satten and labelled "optimization".  I'll ask him if he
remembers what sort of problem case or test suite he was using.
We have many more plot options now than when this optimization was
done, and it could well be either that it has become pointless or
that it is still benificial but has become incomplete.
Either way I'd like to know what the original rationale was.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742