Re: gnuplot slow on BIG files

[<br...@ph...>]

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

>>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. 

That's exactly the error checking I'm talking about.  Without it, 
handling missing or malformed data would be impossible.

 > For true error checking we would
> need strtod, unless I've overlooked some entirely different method.

There's not a lot you could do with strtod() that sscanf() couldn't do 
just as well.

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

> But %n is non-portable, as documented by the OSK comment 

Just because some silly implementation is buggy doesn't exactly mean %n 
is unportable.  %n is as portable as you can ever hope to be: it's an 
ANSI requirement.

> 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.

I dimly remember this being about not running sscanf() on all columns of 
a multi-column data file if no extended using specs are in use.  If you
have "using 1:2:3", you can simply ignore columns 4 to 1000.  If you 
have "using 1:2:(column(some_function($3)), datafile.c has to convert 
all 1000 of them.