Re: Unmark pdumped objects
>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
OG> On Tue, Oct 26, 1999 at 11:11:28AM -0700, Martin Buchholz wrote:
> 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.
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!
> 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.
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.")