From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Compilation to native Date: Wed, 14 Apr 2004 10:54:39 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200404140154.KAA14819@etlken.m17n.org> References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <8765cwkejr.fsf@mail.jurta.org> <200404071157.UAA25094@etlken.m17n.org> <87oepvo4jz.fsf@mail.jurta.org> <200404132340.IAA14502@etlken.m17n.org> <87u0zniciw.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1081908119 14154 80.91.224.253 (14 Apr 2004 02:01:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Apr 2004 02:01:59 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 14 04:01:49 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDZin-0005Md-00 for ; Wed, 14 Apr 2004 04:01:49 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDZin-00019V-00 for ; Wed, 14 Apr 2004 04:01:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDZhE-0006Os-QW for emacs-devel@quimby.gnus.org; Tue, 13 Apr 2004 22:00:12 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDZge-0006Mv-Pr for emacs-devel@gnu.org; Tue, 13 Apr 2004 21:59:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDZcy-0004tI-Cl for emacs-devel@gnu.org; Tue, 13 Apr 2004 21:56:19 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDZby-0003kL-9u; Tue, 13 Apr 2004 21:54:46 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/8.11.6) with ESMTP id i3E1se825125; Wed, 14 Apr 2004 10:54:40 +0900 (JST) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id i3E1sd905457; Wed, 14 Apr 2004 10:54:39 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA14819; Wed, 14 Apr 2004 10:54:39 +0900 (JST) Original-To: juri@jurta.org In-reply-to: <87u0zniciw.fsf@mail.jurta.org> (message from Juri Linkov on Wed, 14 Apr 2004 04:17:11 +0300) 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) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21609 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21609 In article <87u0zniciw.fsf@mail.jurta.org>, Juri Linkov writes: > Kenichi Handa 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 ^@^@^@^@^@^@^@^@ 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 handa@m17n.org