Re: Compilation to native

[Kenichi Handa]

In article <address@hidden>, Juri Linkov <address@hidden> writes:
> Kenichi Handa <address@hidden> writes:
>>  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.

> I don't know how lookups are implemented in emacs-unicode,
> but generally lookups would be very fast when implemented
> on arrays.  Surely, it requires memory, but for small-sized
> alphabets this is acceptable.

It's surely fast, but not as first as this code:

  unsigined char byte = *src++;
  *dst++ = _SOME_LEADING_BYTE_;
  *dst++ = byte;

And please consider the procedure for generating UTF-8 byte
sequence from a character code which contains two or more
conditionals.

Anyway, I have some idea to improve the performance, but
don't want to work on it at the moment.  Synchronizing to
the trunk should be done first.

>>>  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?

> I'm not sure this list is the right place to report bugs on the
> emacs-unicode branch, but here are the symptoms:

Ok, I'll reply in emacs-unicode mailing list including you
in CC:.

---
Ken'ichi HANDA
address@hidden