Re: gnuplot slow on BIG files

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

Hans-Bernhard Br=F6ker wrote:
> Robert Hart wrote:
>=20
>> On Thu, 2005-06-09 at 21:18 +0800, Hans-Bernhard Br=F6ker wrote:
>>
>>> Robert Hart wrote:
>=20
>=20
>>>> strtod() is indeed significantly faster than sscanf.=20
>=20
>=20
>>> And I still don't see why that should be the case...
>=20
>=20
>> 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.=20
>=20
>=20
> None of that extra work can possibly be "a lot", compared to the heavy=20
> task of actually doing a floating-point conversion.  I've inspected lib=
c=20
> source sufficiently to be reasonably sure of that.  There's no way the=20
> format string parser in sscanf() can take 10 times as much time as the=20
> actual floating point parsing (which may very well be done by calling=20
> strtod(), internally).


I think I've found a discussion that parallels what has been here:

http://dbforums.com/t327787.html

See if you agree.  For example:


"So this is a quality-of-implementation issue, at most, and it's not rest=
ricted to
glibc. I've just found O(n^2) on another platform with a different libc, =
too.

BTW: if I change the call from sscanf() to strtod(), the run time becomes=
 O(n)=20
in all
platforms I cared to test. I.e. the difference must happen in sscanf() it=
self,=20
and be
caused by the length of the remainder of the input string following the m=
atched=20
3.14."

Now, here's the interesting part.  :)  The date of this contribution is M=
ay 22,=20
2002.  And the contributor of this was...

Hans-Bernhard Broeker (br...@ph...)

:)