Re: size of emacs executable after unicode merge

[Dan Nicolaescu]

Kenichi Handa <address@hidden> writes:

  > 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.  

Thanks for doing this!

  > It's still 1.6M bytes larger than Emacs 22, but I'm not sure it's
  > worth making more effort to reduce it.

In that case that size increase might be with us for ever and ever,
which is not ideal.

Also a related question: the data in the .map files in
emacs/etc/charsets be transformed into elisp?  That way the normal
loading mechanism could be used for them, and no parser + other code
would be needed...