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] |
Russell McManus <mcmanus@IDT.NET> writes: > Jim Blandy <jimb@red-bean.com> writes: > > > Which would people prefer? > > 1) Guile becomes slower overall, but does not pause noticeable for GC. > > 2) Guile becomes faster overall, and most GC pauses become > > unnoticable, but does still pause occsionally? > > The only thing 1 is better for is games, I would think, since we are > still not providing real-time guarantees. It is also better for GUI:s. If the garbage collector doesn't have some way to prevent collections over all used memory (generational GC doesn't necessarily revent this; see end of my recent reply to Jim), GC pauses can be long if the application is large. Long GC pauses is not compatible with a good GUI. A GUI is a typical thing to write in a scripting language (think of Tcl/Tk). > I vote for 2. Considering the above, do you still vote for 2? > Generational gc is necessary to allow guile to scale up to large > problems effectively. I agree. I'm not opposed to a generational GC, I applaud it. Also, even if Greg's GC will have occasional long GC pauses in large applications I still think it's great. But it is possible to write a generational GC which doesn't have long GC pauses, and I think that is a better solution for Guile. I'm taking up this issue now if it is possible for Greg to take this into account in his design (which I regretfully still haven't studied). /mdj