Re: XEmacs slows down like hell

MS> Yeah, well, note the precondition he's listing: Hans> It is however our experience that in single-threaded Hans> environments with moderately long-lived objects garbage Hans> collection time generally dominates allocation time, even with Hans> noncontiguous free memory. MS> This is true for most pure C and C++ programs where allocation is MS> painful and therefore rare. Not so for Lisp and other more dynamic MS> environments. I think it's true for XEmacs, which is quite stateful compared to most other Lisp environments. For XEmacs, costs of allocation are insignificant compared to the costs of collection, because of the large stable heap. My own measurements indicate that gc costs 5-10 times the cost of allocation. It would be a win to spend twice as much time allocating to get better gc times and locality. The big memory management problem with XEmacs is the size of the heap. MS> For a dissenting oppinion on *that*, along with some hard data to back MS> it up against Boehm's collector, see: MS> http://www.cs.cornell.edu/talc/papers/mcc-ismm-abstract.html Thanks - that was interesting reading. I'm suspicious about MCC, because: - they mention `1000 lines of assembly' (shudder) - they only ever use one platform (sparc + gcc) - where's the source? Martin