[Top][All Lists]

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

Re: Compilation to native

From: Kenichi Handa
Subject: Re: Compilation to native
Date: Wed, 14 Apr 2004 08:40:48 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, Juri Linkov <address@hidden> writes:
> I tested the unicode branch a little.  Visiting a UTF-8 file
> is very fast: a 20MB file under 2 sec!  (Actually, no wonder if
> it's Emacs internal encoding).  Visiting a non-ASCII non-UTF-8
> file is faster than on the trunk, but still is too slow:
> a 7MB file in 30 sec.  Even though the unicode branch doesn't
> use CCL programs, visiting a file in map-encoded charsets
> needs more improvement.

As Emacs-unicode has to map every character in a legacy
charset to Unicode, it's inevitable that such kind of code
version gets slower.  For instance, on reading iso-8859-2
file, Emacs 21 only have to add some leading byte to each
character.  But emacs-unicode has to lookup a table to get a
Unicode character code, and then has to get an UTF-8
byte-sequence for that character code.

> Generally, the unicode branch seems stable on GNU/Linux.
> I have noticed only a few bugs like, for example, sometimes
> displaying a row of 
> address@hidden@address@hidden@address@hidden@address@hidden@ characters 
> instead
> of file names in dired buffers, and some minor problems,
> for example, not finding fonts that the trunk version
> is able to find.

Do you remember the name of fonts that emacs-unicode failed
to find?

> Sorry, I can't test it by everyday use because it lacks
> new features added to the trunk.  I hope it will be merged
> with the trunk soon (after preserving the current trunk
> on a separate branch, of course).

I'm now synchronizing emacs-unicode to trunk version
gradually.  But, it will take more days to finish

Ken'ichi HANDA

reply via email to

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