Re: Emacs is consing like mad

[Kenichi Handa]

Dave Love <address@hidden> writes:
>>>>>>  Andreas Schwab writes:
>>  I have found the culprit: it was Mule-UCS.

> The change I made a while ago to register-char-codings makes my
> (non-default) configuration of Mule-UCS very slow to load.

Right.  I've just tried to revert register-char-codings back
and load un-define.elc.  Then, at least the loading was as
fast as previous.

> It probably needs himi to say why exactly, but that
> function is probably called at least once for each base
> coding system defined. (It doesn't strictly need to be,
> since all the utf variants encode the same characters, but
> you'd have to subvert make-coding-system to avoid it.)

> The change was due to a problem exposed by Mule-UCS, but if I made any
> design choices, they were for more usual applications.  Maybe someone
> can re-write it more efficiently for such a case if they understand
> the issues, but the Mule list already had the chance and it's somewhat
> tricky to get right and please don't clobber more normal cases.  handa
> may want to comment further.

I have an idea of making register-char-codings more
effcient, i.e. not consing that much.  The outline of the
strategy is:

(1) For all non-generic-chars to register, record the
    generic char (instead of the charset) in the sencond
    extra slot of char-coding-system-table.  Actually, this
    is done while doing (3).

(2) Modify the arg SAFE-CHAR so that it has individual
    elements for all generic chars listed by (1).

(3) Execute map-char-table on safe-chars as we did
    previously while also doing (1).  The generic char to
    record can be get by (if KEY is not a generic char):
        (apply 'make-char (butlast (split-char KEY)))
    As it is expected that the number of non-generic-chars
    are small, the consing by the above code won't be a
    problem.

Dave, what do you think?  Can you implment it?  If you or
the other person don't have time to do that, please wait
until when I can contribute codes again.

---
Ken'ichi HANDA
address@hidden