(seeks while reading) Re: Performance, argh

[Telford Tendys <telford@eng.uts.edu.au>]

On Sat, Jul 10, 1999 at 04:08:25PM -0700, Greg Badros wrote:
> Lalo Martins <lalo@webcom.com> writes:
> 
> > IMVHO, Perl and Python have small startup times due to
> > "semicompiled" (or byte-compiled or whatever each language calls
> > them) modules. Perhaps coming up with a ".gscmc" format is all
> > we need to get this particular ghost past us.
> 
> Unless this a really new thing, Perl doesn't do it; it just translates
> really quickly.  (You're right for Python, though, and the approach
> certainly would transfer to the guile world).

By the time guile has done its memoise on a function, the function is
probably `compiled' to the same extent that perl functions are. The
trouble is that perl gets to this point a lot quicker than guile does.

I'm still fiddling with the libguile.so.4 from the Debian slink binary
release so I'm not up with the latest snapshots. However, when I do an
strace on a guile program I notice horribly large numbers of seek() and
read() operations happening. It seems to read ahead a long way and then
seek back for each and every character! Am I out of touch and this is
a known bug that is already fixed? Is it on the TODO list? My guess is
that this is what is eating the startup time.

I have heard people say that ports need a rewrite, my guess is that
it would be better to avoid the C library routines fopen() etc.. and
to do the buffering in guile instead. The other thing that I was thinking
is to do the line numbering in a second pass rather than at the same time
as normal reads. This is because the line numbering is not always
wanted and causes quite a slowdown. My idea was to just scan out the whole
file and make a table that relates seek number to line number then
do the reading without worrying about line numbers.

	- Tel