Re: size of emacs executable after unicode merge

[Kenichi Handa]

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
address@hidden

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?