Re: [Chicken-users] Is there interest in a new egg (fast-io)?

[Jeronimo Pellegrini]

Hello!

On Thu, Apr 22, 2010 at 02:25:00PM -0500, Jim Ursetto wrote:
> Here are my numbers:
> 
>             scheme  fast-io  line  numbers 1.8   2.1
> ------------------------------------------------------
> write fixnum    26       21    26           26
> read  fixnum    61       20    22          211   193
> write flonum    48       25    48           50
> read  flonum    86       24    25          276   246
> 
> where
> "scheme" is your code without numbers loaded,
> "fast-io" is your fast-io code,
> "numbers" is your code with numbers version 1.8 or 2.1 loaded,
> "line" is my fast scheme implementation.
> 
> CPU performance disparity aside, I don't get nearly the
> slowdown that you do with plain scheme (read), so my guess is
> that either you loaded the numbers egg or that fast-io
> is inexplicably slow on my machine.  I presume you
> loaded numbers because your complex test did not work
> without it.

Yes, I used the numbers egg, that's right. I wasn't expecting
that it would slow down reading and writing of flonums and
fixnums that much.

> Furthermore the "line" implementation is basically on par
> with fast-io, as long as numbers is not loaded.
> 
> To get the "line" implementation for readers all you need to do
> is replace (read port) with (string->number (read-line port)).
> Furthermore when you generate the files, use a newline
> delimiter instead of a space.
> 
> "line" is faster than "scheme" by 3-4x because read is
> more general and more importantly, because (read)
> is character based and char-based I/O from stream ports
> is really slow on Chicken.  On the other hand, line and string
> based I/O is fast.

That makes sense -- by reading a sequence of characters and
then using string->number you used a somewhat similar idea
that I used myself (if you *know* it's a number, don't try
to parse a string or S-expression or anything else).

> Based on this admittedly quick test, there's not much
> advantage to using fast-io as long as your data is
> newline-delimited.

Yes, it looks like that.

> What might be useful is a read-delimited-string (or whatever)
> which would read until a specified set of delimiters.

It's on the latest version of the egg!
(read-string-until CHAR PORT) 
(read-string-between LEFTCHAR RIGHTCHAR PORT)

I didn't yet include read-string-n because it's an identifier
used in R6RS, and may (who knows) end up in the next standard
(R7RS or whatever it will be called -- as far as I know there
is no name for it yet) when it comes out.

> This wouldn't replace read-line--as newlines are handled
> specially due to \r--nor would it handle escaped chars,
> but it would handle the basic case of reading strings until
> NUL or SPACE.

> Or you could preprocess your space-delimited files with
>  tr ' ' '\012'
> :)

Thanks for pointing this out! I'll still use specialized-io
myself (my files have several numbers per line, with some
strings there too).

For human-unreadable fast I/O maybe converting numbers into
binary and writing blobs would be faster.

J.