Daniel Pittman wrote:

On Mon, 18 Mar 2002, Ben Wing wrote:

Side note: `string-memq' is gone in ben-mule. This is vaguely irritating
to me because I use it in my init file...

i have no clue. i wish you could find out; it doesn't happen for me. 
my xemacs.exe is using 15 MB.


Lucky you. I get ~70MB of image by the time it hits the splash screen,
though memprof reports that only 25MB or so of that lives through an
initial GC at that stage.

[...]

i wrote a fun to show memory usage.  update to the latest cvs and do


That shows nothing particularly useful or unusual, at least for me, but
then, neither did my hacked up version of the same. :)

What /does/ show up is the reason why the XEmacs image balloons to 80MB
or so during startup.

Fdowncase, through casify_object and make_string mallocs 36,057,648
bytes of data during startup. That seems ... excessive to me.

Once the startup is done and XEmacs is sitting in the *scratch* buffer
this drops to some 59,236 bytes still allocated. So, this is clearly
temporary data -- it's just very *big* temporary data.

Perhaps this can be done during the build process rather than every
startup?

well, it probably shouldn't be happening at all.
do you still get the same problem if you run -vanilla?
if not, you should be able to isolate what in your init file is causing the problem.

if so, we should start with the call to Fdowncase. i only see a few places where this could possibly be ballooning -- either in the x font code or maybe in the mule startup code, through assoc-ignore-case. try compiling without mule support and see whether the problem goes away.

another thing to do, if you have the patience, is to modify the Fdowncase code by inserting a call to debug_backtrace() [or maybe debug_short_backtrace()]. save stderr to a file and you should have a REALLY BIG file which you should be able to process to find out where the call is coming from.




set_unicode_conversion /isn't/ the problem here, incidentally. It's
sitting at 683,776 bytes allocated internally; big, but well within
sensible limits.


The rest of the code looks fairly reasonable; the footprint problem is
mostly that the init code builds such a huge image and that the memory
allocated never gets handed back to the OS...

        Daniel