[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: Thu, 27 Nov 2008 20:20:21 +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:

> Kenichi Handa <address@hidden> writes:
>>> > 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.
> >
> > 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?

> Commenting out the calls to unify-charset does reduce the memory by
> several megabytes.

After taking over Chong's experiment, I could reduce the
size of Emacs executables about 7M bytes.  About 4M bytes
were actually because of charset mapping tables, and it
could be reduced by setting up C structure temp_charset_work
(see charset.c for the detail) instead of making many Lisp
objects (char-table and vector).  Another 3M bytes were
because of big standard category table.  It could be reduced
by hashing the table entries (see hash_get_category_set in
category.c for the detail).

As a result, now the executable is 10,671,313 bytes on
GNU/Linux.  It's still 1.6M bytes larger than Emacs 22, but
I'm not sure it's worth making more effort to reduce it.

Kenichi Handa

reply via email to

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