This is the mail archive of the firstname.lastname@example.org 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]|
email@example.com writes: > > I compiled -O2 -g. I gave up on looking at profiling output & just > started hacking out pieces of scm_regexp_exec one at a time to see > where the time was spent. (BTW, this is under linux, rh4.2, gcc > 184.108.40.206 & on a pentium II 300. My other tests were on a similar linux > setup but on a pentium 120). > > Here're the results: > > > This leaves two questions: > > 1. How much does guile's eval differ from scm's? I think there are two key differences. First, SCM's eval has been optimized further since the fork with Guile and is therefore intrinsically faster in some ways (including, notably, on local variable allocation/deallocation). Second, the current module system is widely believed to slow down eval to a non-trivial degree. It would be possible to test the latter hypothesis by building a hacked guile executable that did not load boot-9.scm, but this would also affect point 2 below. > 2. How much more time is guile spending in gc because it's initially > sucking up so much code? Guile's GC is O(size of the heap) so this almost certainly makes a difference. For reasons mentioned above It seems kind of a cop-out to attribute nearly every Guile performance problem of any kind to the module system, but it seems to be true in a lot of cases. > 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. > I agree with this sentiment overall. Even when the init files are nicely cleaned up it would probably _still_ be better to ship them so they install compiled. However, the Guile-modified version of Hobbit is not necessarily ready for prime-time yet. Perhaps the freezer or the unexec stuff could make a livable stopgap measure? - Maciej