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. MS> Are you telling me GC may account for >50% of the running time of MS> XEmacs? (Of course, the benchmark I posted is biased towards GC, but MS> a slowdown of 2 feels about right.) Yes. You can't manage what you can't measure (unless you're managing humans, in which case the reverse holds). If XEmacs generates garbage in a loop, running time will generally be gc-bound. (compile-and-profile (let ((x 0) (table (make-hash-table))) (while (< (incf x) 1000000) (puthash 1 (cons x x) table)))) ==> Function Name Ticks %/Total Call Count ============================ ===== ======= ========== (in garbage collection) 1710 81.936 compiled-code-being-profiled 235 11.260 1 puthash 142 6.804 999999 ------------------------------------------------------------- Total 2087 100.00 (Note how cheap puthash is, contrary to expectations) Here we get a factor of 5 slowdown in my `work' xemacs running VM and lots of assorted other stuff. A fresh xemacs would have a different gc profile. Hmmm, OK, let's measure: Function Name Ticks %/Total Call Count ============================ ===== ======= ========== (in garbage collection) 332 46.111 compiled-code-being-profiled 230 31.944 1 puthash 158 21.944 999999 -------------------------------------------------------------