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] |
hjstein@bfr.co.il (Harvey J. Stein) writes: > guile> (define (fact n) (if (< n 1) 1 (* n (fact (- n 1))))) > [...] > ERROR: Stack overflow > ABORT: (stack-overflow) [You know that you can tell Guile how loarga a stack it should accept? (debug-set! stack <n>)] > guile> (define (factstart s n) (if (< n 1) s (factstart (* s n) (- n 1)))) > And, before this generates 30 messages about what exactly this above > test shows, I'd like to also point out the obvious - the above test is > probably more of the speed of the bignum subsystem, than the > interpreter itself. Yes, indeed, and very much so. It probably spends 95% of the time in the bignum package. STk uses the gmp library. > On "real" applications, I've also found STk to be faster than guile. > This time, it might be the I/O subsystem, or the regexp subsystem, or > ... I'd very interested if you could show me one other real example. > But the more this occurs, the more it makes it looks like a large > part of guile is just slow. The current I/O system has a stupid architecture. But apart from that I'd claim that most of Guile is fast. > In any case, lets get back to the issue at hand - how about turning > off debugging by default? It makes guile look bad, it causes users to > flee, developers can turn it on for development, the fact that it > bulks up the code during reading (a guess) is probably having a bad > interaction with the GC causing *loading* with debugging turned on to > slow down code that's *run* with debugging turned off, ... Well, I could accept such a change. Let's hear what Jim has to say about it. /mdj