[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: Wed, 05 Nov 2008 13:17:40 +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:

> Stefan Monnier <address@hidden> writes:
> > Maybe simpler would be to build this table as we do now, then print it
> > into a file.  Then the "dump" doesn't need to build the table, it can
> > just read it from the file.

> Handa-san, could you comment on this?

I think it doesn't work.  Emacs needs that table and the other
mapping char-tables to decode non-ascii characters in files
that are loaded before dumping.

> Suppose we have a char-table on file that has the correct precomputed
> values for Vchar_unify_table.  At which point should Emacs load it?  In
> place of mule-conf.el in loadup.el?  Or would we need to rewrite
> mule-conf.el?

Once Emacs loads it before dumping, it occupies Emacs memory
and whether it is freed or not before dumping is

If it is impossible to exlucde garbage-colleted data
(especially char-tables) from the dumpled file, it seems
that the only way is not to build those char-tables.  But it
requires rather heavy changes to files loaded before dumped.

Anoher way to avoid this problem is, I think, to have a
portable dumper.

Kenichi Handa

reply via email to

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