From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Case mapping of sharp s Date: Tue, 24 Nov 2009 21:26:17 +0900 Message-ID: References: <4B05A11F.5000700@gmx.de> <4B05D3EE.2000101@gmx.de> <4B0759BA.2010303@gmx.de> <19207.50135.691132.983395@a1i15.kph.uni-mainz.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259065617 27282 80.91.229.12 (24 Nov 2009 12:26:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 12:26:57 +0000 (UTC) Cc: ulm@gentoo.org, emacs-devel@gnu.org, grishka@gmx.de, monnier@iro.umontreal.ca To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 24 13:26:49 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NCuTn-00046R-5G for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 13:26:47 +0100 Original-Received: from localhost ([127.0.0.1]:46704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCuTm-0001PI-HO for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 07:26:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCuTd-0001Om-9i for emacs-devel@gnu.org; Tue, 24 Nov 2009 07:26:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCuTY-0001O1-L9 for emacs-devel@gnu.org; Tue, 24 Nov 2009 07:26:36 -0500 Original-Received: from [199.232.76.173] (port=37127 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCuTY-0001Ny-E7 for emacs-devel@gnu.org; Tue, 24 Nov 2009 07:26:32 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:63479) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCuTX-00074V-II for emacs-devel@gnu.org; Tue, 24 Nov 2009 07:26:32 -0500 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id nAOCQIms028882; Tue, 24 Nov 2009 21:26:18 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id nAOCQIlP011481; Tue, 24 Nov 2009 21:26:18 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id nAOCQHXh012451; Tue, 24 Nov 2009 21:26:17 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1NCuTJ-0006NE-Gg; Tue, 24 Nov 2009 21:26:17 +0900 In-Reply-To: (message from Andreas Schwab on Sat, 21 Nov 2009 12:58:25 +0100) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:117673 Archived-At: In article , Andreas Schwab writes: > Ulrich Mueller writes: > > Is that the reason for the backwards search in ERC buffers being > > extremely slow? It may keep Emacs busy for several *minutes*. And it's > > not interruptible with C-g. > Does this patch help? Here are some ideas to improve it. (1) Do forward matching in backward search. The original code roughly does this to search "012abc" for "012" from the tail. check if "012" matches with "abc" check if "012" matches with "2ab" ... But the new code does this: check if "210" matches with "cba" check if "210" matches with "ba2" ... As INC_BOTH is faster than DEC_BOTH, the original way of check matching is faster. The slowness of the orignal code was caused by using CHAR_TO_BYTE to find the place of "2" when you know the place of "a". Use DEC_BOTH here only. (2) Pre-compute the character codes in PAT in an integer array if LEN is not that long (perhaps LEN < 256, or at most, sizeof (int) * LEN < MAX_ALLOCA). Then, you don't need the repeated STRING_CHAR on PAT. This can be applicable to forward search too. (3) In addition to (2), pre-compute the character codes in BUF too in an array of the same length as (2). Then you can avoid using STRING_CHAR and TRANSLATE repeatedly on the same place of BUF. This requires modulo calculation to get an index of the array, but I think it's faster than the combination of STRING_CHAR and TRANSLATE. --- Kenichi Handa handa@m17n.org