This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Harvey- Wow. You have done a lot of work benchmarking guile. "Harvey J. Stein" <hjstein@bfr.co.il> writes: > This leaves two questions: > > 1. How much does guile's eval differ from scm's? > 2. How much more time is guile spending in gc because it's initially > sucking up so much code? > > If the problem really is in 2, then it means that either we need a > generational gc for guile (hard), or it *must* ship with compiled init > files (not hard). The latter would also help startup time & would > make the stuff in the init files run faster. I really don't > understand the resistance to doing this. I know there are things that > *should* be done with the startup files that would speed things up, > but why not just compile them anyway? At least people wouldn't have > to live through the startup times waiting for the day when things are > cleaned up. It's just a simple matter of programming... ;^) Actually I agree with you that guile should either ship with a bare interpreter that starts up really fast, or with compiled init files so that the full interpreter can start up really fast. Jim has said in the past that he thinks that startup can be really fast even if scheme files are loaded, but I'm skeptical of this. I'm not doing any coding in this area so I'm no expert. I guess the focus is on getting the init sequence correct, before making it fast (avoid premature optimization, you know). In principle, I agree with this, but I also hate waiting for guile to start up. > A general testing issue - Doing benchmarking is a pain because of the > need to include (debug-disable 'debug) at the top of files means I > need different files for other scheme implementations. How about also > -nodebug & -debug command line args & make the (configurable) default > -nodebug? A couple of things tangentially related jump to mind. guile may have been reading your $HOME/.guile file, or at least checking for it's existence. guile performs a large number of stat's when finding it's initialization files (the snapshot I am running performed 42 stat system calls while starting up). guile called brk 32 times while starting up on my solaris 2.5.1 ultra1 box, which means that it should probably increase the amount of memory allocated on startup, to avoid most of these system calls. (libc may be calling brk, of course, but it's worth looking into). -Russ -- "Windows NT "is an acronym for "Windows? No thanks."