[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: size of emacs executable after unicode merge

From: Kenichi Handa
Subject: Re: size of emacs executable after unicode merge
Date: Wed, 12 Nov 2008 15:26:01 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Chong Yidong <address@hidden> writes:

> Okay, I did a bit more digging.
> I think the increase in the size of the Emacs executable is not due to
> the allocation of char-tables.  In particular, I've tried this
> suggestion:

> > One idea is to have a single boolean vector of size #x110000
> > (139264 bytes), setup it for CHARSET everytime when we call
> > map-charset-chars for the different charset.  In that
> > vector, only the bit for #x3000, #x3001, #x3002, etc are 1
> > for chinese-gb2312.  Then map-charset-chars can know for
> > which characters FUNCTION must be called.

> but it appears to free a negligible about of memory.

But, that contradicts with this report from Yamamoto-san:

> Anyway, an experiment on Mac OS X (*1) shows that clear-charset-maps
> followed by GC actually collects some amount of data in heap (~7MB),
> but they are not returned to the system, at least with its malloc
> implementation.

Did you comment out the calls of unify-charset in
mule-conf.el and change the encoding of all preloaded *.el
files to utf-8?

Kenichi Handa

PS.  Yidong, it seems that a few mails I wrote in this
24-hour didn't go out correctly.   Did you get a mail about
the comment on map_char_table_for_charset?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]