Re: XEmacs slows down like hell

Martin> It's certainly possible that our lisp allocation bookkeeping is Martin> somehow broken. However... Martin> It is clear that the cost of one gc should be proportional to the Martin> amount of lisp storage allocated. If many elisp libraries are loaded, Martin> then there will be more lisp storage in the form of bytecode Martin> functions. But if a huge amount of lisp storage is allocated and Martin> subsequently freed, gc should not be much slower afterwards. Are you telling me GC may account for >50% of the running time of XEmacs? (Of course, the benchmark I posted is biased towards GC, but a slowdown of 2 feels about right.) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla