Re: gnuplot slow on BIG files

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

On Thursday 09 June 2005 07:44 pm, Hans-Bernhard Br=F6ker wrote:
>
> 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.

A bit of poking around on the web leads me to the conclusion that
there is no single libc for OS9/OSK.  There are many, including
(since 1994) gcc and glibc.  Trying to figure out which of these
long ago libc variants was having a problem with %n is probably
a lost cause.  To the extent we can assume anything, I think we can
assume that a glibc implemtation provides strtod and follows the
ANSI requirement that strtod and scanf use the same format rules.

This is beating a dead horse, though.  The whole point of OSK is
that it runs in minimal RAM on embedded systems on old hardware.
I don't believe for a minute that anyone is going to install a
full-blown gnuplot version 4.2 on one of these old devices.

I suggest that we concentrate on the more relevant point of whether a
2X or 5X or 10X or whatever speed-up is worth the slight uncertainty
of replacing the current scanf() call with strtod().  ANSI says they
behave the same on formatting, and benchmarking shows that strtod()
is faster.  Sounds like a win to me. =20

The strongest counter-argument I see is that if you really want to
read in these huge matrices, you're better off using the binary
input mode anyhow.  Or if binary mode is not faster, then we should be
fixing that first.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742