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] |
Russ McManus <russell.mcmanus@gs.com> writes: > I think it is a basic requirement for guile to be able to work with > large data sets. Without some form of generational gc, gc time starts > to dominate run time, so I think we need a generational gc. I'm not > sure if this means a vote for 1 or 2! Both 1 and 2 are compatible with a generational gc. > With a generational gc, you sometimes get a scan of the whole data > space, which will necessarily be slow when the data set is large. So > I don't know how to get around occassional long pauses, so I think > I'm still voting for 2. But if 1 has the ability to handle large > data sets, then I would vote for that one instead. 1 would be able to handle large data sets and would have a performance which scales as well as 2 when the problem size grows. The difference is that 1 would be slower than 2 by a constant factor because it has to do more bookkeeping. A wild guess would be that 1 would have 20-25% longer execution time. What I'm trying to argue in this discussion is that the difference between 1 and 2 with regard to execution speed is a difference in degree while 2 makes it hard to write GUI:s with a nice behaviour, that is, it excludes one class of application of Guile. > BTW, I use guile right now for GUI programs (linked into Motif > programs), and the collections are noticeable to the user, so > improvements in this area are very welcome! Well, this is my experience too. I wonder if those who argue for alternative 2 really have tried to write larger user interfaces in Guile... (with exception of Harvey Stein who have managed to get smooth performance in STk by using a larger initial heap and calling gc in the scheme code). /mdj