[Top][All Lists]

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

Re: size of emacs executable after unicode merge

From: Chong Yidong
Subject: Re: size of emacs executable after unicode merge
Date: Thu, 13 Nov 2008 11:33:40 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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.

But I'm not sure I understand your idea correctly.  Here's the approach
I tried, do you think it is correct?

- introduce a variable called inhibit-load-charsets-map, defaulting to

- In loadup.el, let-bind inhibit-load-charsets-map to t when loading

- In map_charset_chars, when inhibit-load-charsets-map is non-nil, and
  the charset method is deferred, don't call load_charset and
  map_char_table_for_charset.  Instead, call a new function

- The new function map_charset_chars_from_file reads the code points and
  character codes from the charset file and applies the function
  argument passed to map_charset_chars on those codes directly.

Would this work?

reply via email to

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