Ar an naoú lá déag de mí na Nollaig, scríobh Nix: 
 > I know, I'm saying the memory usage *reported by XEmacs*
seems
 > reasonable. The bloat is not accounted for by objects we count, not
 > even as a proportion, right?
 
 Indeed not: `object-memory-usage-stats' reports sane values. The problem
 is the actual amount of memory allocated (which is all, or nearly all,
 traversed by the garbage collector: RSS goes up just as fast as VSZ.)
 
 ... hm. I just remembered Ulrich Drepper and Wolfram Gloger mentioning
 (I think on libc-alpha a while back but it may have been in some paper
 somewhere) that the glibc malloc hooks are pretty much completely broken
 and don't work properly, especially in glibc 2.4+: as far as I can tell
 we don't rely on those hooks except when terminating (to a very limited
 degree) and as a debugging hack with no effect on memory-allocation
 semantics, right?
 
 (if so, damn, I'll have to actually do some *work* to diagnose this
 rather than leaping directly to the solution by magic. :) ) 
The comp.unix.programmer FAQ approach to generating a stack trace and
wrapping malloc() with something that calls that would probably give an
exact idea of what’s calling what, irrespective of the malloc
implementation. Dog-slow, though. 
Tangentally, has anyone got experience running XEmacs under valgrind? One
would need to do the temacs -batch -l ../lisp/loadup.el run-temacs thing, I
imagine, but it might help. (Am on NetBSD for my dev machine, which doesn’t
support it, unhappily.)
-- 
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta