From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: very slow archive-mode Date: Fri, 14 Mar 2008 10:56:14 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <200803122247.58553.pogonyshev@gmx.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1205459796 18183 80.91.229.12 (14 Mar 2008 01:56:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 01:56:36 +0000 (UTC) Cc: pogonyshev@gmx.net, emacs-devel@gnu.org, Kenichi Handa To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 02:57:04 2008 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 1JZzAM-0006jH-Pu for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 02:57:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZz9n-0000uZ-N5 for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 21:56:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZz9i-0000sZ-Ju for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:56:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZz9h-0000r7-0p for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:56:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZz9g-0000r4-PI for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:56:20 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2] helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JZz9g-0005Jx-Ac for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:56:20 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 4CDEB2C46; Fri, 14 Mar 2008 10:56:14 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:92468 Archived-At: >>>>> On Thu, 13 Mar 2008 11:08:52 -0400, Stefan Monnier said: >>> I reported a similar problem. I believe set-buffer-multibyte is >>> *a lot* slower now, and may even have a time complexity of O(N^2). >> I suspect so too. Now set-buffer-multibyte must convert more 8-bit >> bytes to mutlibyte forms and that results in more movement and >> increasing of the gap. This code: > Also, IIUC the 8-bit bytes that are not represented as a single byte > and not only more numerous, but they also take up more space (they > used to take up just 2 bytes but now they take up what 3? 4? 5 > bytes?). IIUC, it still takes up just 2 bytes by cleverly using vacant UTF-8 area (see character.h). I think code_convert_region in Emacs 22 tried to avoid the repeated reallocations and copies by estimating the necessary buffer size from the intermediate result of conversion in progress. (And there were a cast problem that affected its performance: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-12/msg00197.html) Does the code conversion in Emacs 23 include such estimation? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp