[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: size of emacs executable after unicode merge
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: size of emacs executable after unicode merge |
Date: |
Sat, 17 May 2008 10:52:33 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Sat, 17 May 2008 09:56:58 +0900, Kenichi Handa <address@hidden> said:
> They are surely loaded on demand. And, at the end of the dumping
> process, by calling clear-charset-maps, all loaded maps are set to
> nil, and then garbage-collect is called. So I think they are not
> included in the dumped Emacs. Perhaps some other char-table is the
> culprit. Maybe Vchar_unify_table. I must re-read src/charset.c.
I tried taking some heap statistics during loadup on Mac OS X. It
would be interesting to focus on the changes in the numbers of
1024-byte blocks and 48-byte blocks as they are major factors of the
increase/decrease.
The major increases in the used heap size are observed at the load of
international/mule-conf (564KB -> 8897KB) and
international/characters (9627KB -> 14685KB).
Before loading international/mule-conf:
Overall size: 9359KB; 1512 nodes malloced for 564KB (6% of capacity); largest
unused: [0x1855e00-7848KB]
# of 1024-byte blocks: 193 # of 48-byte blocks: 959
After loading international/mule-conf:
Overall size: 9623KB; 18028 nodes malloced for 8897KB (92% of capacity);
largest unused: [0xe89920-473KB]
# of 1024-byte blocks: 7858 # of 48-byte blocks: 9035
Before loading international/characters:
Overall size: 18123KB; 19500 nodes malloced for 9627KB (53% of capacity);
largest unused: [0x2041e00-7928KB]
# of 1024-byte blocks: 8106 # of 48-byte blocks: 9969
After loading international/characters:
Overall size: 23243KB; 102539 nodes malloced for 14685KB (63% of capacity);
largest unused: [0x2155800-6825KB]
# of 1024-byte blocks: 9358 # of 48-byte blocks: 91721
The clear-charset-maps call followed by garbage-collect surely reduces
the size of the used area (15958KB -> 9188KB), but the unused area is
not returned to the system at least on Mac OS X (i.e., "Overall size"
does not change).
Before clear-charset-maps:
Overall size: 23703KB; 105317 nodes malloced for 15958KB (67% of capacity);
largest unused: [0x222c000-5967KB]
# of 1024-byte blocks: 9865 # of 48-byte blocks: 92577
After clear-charset-maps with garbage-collect:
Overall size: 23703KB; 91717 nodes malloced for 9188KB (38% of capacity);
largest unused: [0x222c000-5967KB]
# of 1024-byte blocks: 3484 # of 48-byte blocks: 85777
FYI, below is the final result of Emacs 22.2.50.
Overall size: 10023KB; 18828 nodes malloced for 3319KB (33% of capacity);
largest unused: [0x19ae000-6471KB]
# of 1024-byte blocks: 1245 # of 48-byte blocks: 15510
YAMAMOTO Mitsuharu
address@hidden
- Re: size of emacs executable after unicode merge, (continued)
- Re: size of emacs executable after unicode merge, Richard M Stallman, 2008/05/15
- Re: size of emacs executable after unicode merge, Dan Nicolaescu, 2008/05/15
- Re: size of emacs executable after unicode merge, Richard M Stallman, 2008/05/16
- Re: size of emacs executable after unicode merge, Dan Nicolaescu, 2008/05/16
- Re: size of emacs executable after unicode merge, Kenichi Handa, 2008/05/16
- Re: size of emacs executable after unicode merge, Jason Rumney, 2008/05/16
- Re: size of emacs executable after unicode merge, Thomas Lord, 2008/05/16
- Re: size of emacs executable after unicode merge, Stephen J. Turnbull, 2008/05/16
- Re: size of emacs executable after unicode merge, Thomas Lord, 2008/05/16
- Re: size of emacs executable after unicode merge, Kenichi Handa, 2008/05/16
- Re: size of emacs executable after unicode merge,
YAMAMOTO Mitsuharu <=
- Re: size of emacs executable after unicode merge, Kenichi Handa, 2008/05/18