On May 16, 2008, at 7:08 PM, William D Clinger wrote: > Some possibilities for the poor load time: > > bug in compiler (such as using eq? hash tables, > which are much slower with the stop-and-copy > collector than with the generational) > > bug in Larceny's stop-and-copy garbage collector > (unlikely) > > stop-and-copy collection really is that much > slower when Twobit is compiling a large > program
I believe the stopcopy collector for Intel native Larceny on the trunk of the development tree suffers from at least one severe performance bug that we identified and I fixed on a development branch back in February. That bug may be causing Ryan's load time problems. See changeset:5429, whose log message has links to some relevant Tickets describing the problem. http://larceny.ccs.neu.edu/larceny-trac/changeset/5429 I have been meaning to fix Tickets #119 and #335 for Intel native on the trunk since February; I have had higher priority concerns for a while, but now would be a good time for me to do that task. (My understanding of Larceny's collectors has matured considerably between when I first opened Ticket #119 two years ago and when I identified #119 as a severe performance bug during some benchmarking 3 months ago, so I think I can come up with an appropriate short-term fix for the trunk over the weekend. Merging changeset:5429 into the trunk could very well be the best short-term fix.) -Felix _______________________________________________ Larceny-users mailing list [email protected] https://lists.ccs.neu.edu/bin/listinfo/larceny-users
