Re: gnuplot slow on BIG files

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

Robert Hart wrote:
> On Thu, 2005-06-09 at 21:18 +0800, Hans-Bernhard Bröker wrote:
>>Robert Hart wrote:

>>>strtod() is indeed significantly faster than sscanf. 

>>And I still don't see why that should be the case...

> sscanf takes an arbitrary format string as an argument, which it must
> parse every time it is called, it is also very generic so, I imagine,
> ends up doing a lot of extra work to support this. 

None of that extra work can possibly be "a lot", compared to the heavy 
task of actually doing a floating-point conversion.  I've inspected libc 
source sufficiently to be reasonably sure of that.  There's no way the 
format string parser in sscanf() can take 10 times as much time as the 
actual floating point parsing (which may very well be done by calling 
strtod(), internally).

>>  /* cannot trust strtod - eg strtod("-",&p) */

> I've seen this comment, and tried it out. In my tests this isn't an
> issue. The man page says:
> 
>        If  no  conversion is performed, zero is returned and the value of nptr
>        is stored in the location referenced by endptr.

That's the manpage of one system.  "To trust" means we must be sure that 
all implementations on the planet get this right.  Are we?

> I have attached my test program. I can't find any input on my system
> that gives different results between sscanf and strtod.

"On my system" being the key phrase here, which means that the test is 
inconclusive.

> Well comments in the code say "%n" doesn't work on OSK.  I don't even
> know what OSK is, 

It's actually called OS-9, a realtime OS for 68000 processors IIRC.

> but if strtod works where sscanf doesn't then that's a win.

IF.  But we don't know that.