Hrv> Olivier Galibert <galibert(a)pobox.com&gt; writes: Hrv> Only "may". If you can find the size of the dumped code with and Hrv> without o-c-f dumping and present us the two numbers, it might very Hrv> well prove that the size increase is irrelevant. It used to be, when you build XEmacs in debug mode, that it would print out the sizes of things, including byte-code stuff, when it dumped. Olivier, you could try building one of those ancient pre-pdump XEmacsen and see what happens. That sort of information *is* useful for core C developers such as yourself. The original bytecode string is discarded (and ``re-constructed'' when the user calls compiled-function-instructions or disassemble), so there is effectively NO extra space used, in fact there may be a slight saving in space when the original compiled function instructions are (hopefully) garbage collected. Martin

OG> On Tue, Oct 26, 1999 at 11:11:28AM -0700, Martin Buchholz wrote: OG> Sure it is. But it was printing _purespace_ stats only. I'm thinking OG> abour writing a subr that could give a vector with this kind of OG> information at any time. I'm interessed by the object uses when OG> running real applications too, not only at dump time. Yes! OG> Of course, I don't dump what is not referenced. I'm going to compile OG> with and without systematic o-c-f and compare the size of xemacs.dmp. Of course, it goes without saying that one of the last things (dump-emacs) does is garbage_collect(). My feeling is that o-c-f should be called on *all* compiled-function objects at dump time. Martin (There is a saying that goes, "Those who say `It goes without saying' rarely go without saying it.")