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 08:40:48 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200404132340.IAA14502@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> 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 1081900214 366 80.91.224.253 (13 Apr 2004 23:50:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2004 23:50:14 +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 01:49:58 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 1BDXfB-0000H4-00 for ; Wed, 14 Apr 2004 01:49:57 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDXfB-00080M-00 for ; Wed, 14 Apr 2004 01:49:57 +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 1BDXal-0005rm-E8 for emacs-devel@quimby.gnus.org; Tue, 13 Apr 2004 19:45:23 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDXXZ-0004Se-Ts for emacs-devel@gnu.org; Tue, 13 Apr 2004 19:42:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDXWv-0004C1-Qd for emacs-devel@gnu.org; Tue, 13 Apr 2004 19:41:57 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDXWP-00040E-9n; Tue, 13 Apr 2004 19:40:53 -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 i3DNem822319; Wed, 14 Apr 2004 08:40:48 +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 i3DNem903557; Wed, 14 Apr 2004 08:40:48 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id IAA14502; Wed, 14 Apr 2004 08:40:48 +0900 (JST) Original-To: juri@jurta.org In-reply-to: <87oepvo4jz.fsf@mail.jurta.org> (message from Juri Linkov on Wed, 14 Apr 2004 02:12:48 +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:21604 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21604 In article <87oepvo4jz.fsf@mail.jurta.org>, Juri Linkov 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 ^@^@^@^@^@^@^@^@ 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 synchronizing. --- Ken'ichi HANDA handa@m17n.org