From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: RMAIL slows Date: Fri, 08 Apr 2005 18:57:23 -0400 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1113002232 28337 80.91.229.2 (8 Apr 2005 23:17:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2005 23:17:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 09 01:17:10 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DK2hx-0006Ju-4i for ged-emacs-devel@m.gmane.org; Sat, 09 Apr 2005 01:16:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DK2HX-0004rv-Rz for ged-emacs-devel@m.gmane.org; Fri, 08 Apr 2005 18:48:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DK2FZ-00044O-Fz for emacs-devel@gnu.org; Fri, 08 Apr 2005 18:46:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DK2C7-0003Pi-NC for emacs-devel@gnu.org; Fri, 08 Apr 2005 18:43:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DK2C5-0003Gq-7l for emacs-devel@gnu.org; Fri, 08 Apr 2005 18:43:17 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DK2Qg-0007B2-KL for emacs-devel@gnu.org; Fri, 08 Apr 2005 18:58:22 -0400 Original-Received: from empanada.home ([67.68.217.126]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050408225723.CKVN1621.simmts7-srv.bellnexxia.net@empanada.home>; Fri, 8 Apr 2005 18:57:23 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id 7B7DD4D7A22; Fri, 8 Apr 2005 18:57:23 -0400 (EDT) Original-To: bob@rattlesnake.com In-Reply-To: (Robert J. Chassell's message of "Fri, 8 Apr 2005 19:40:25 +0000 (UTC)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin) 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:35782 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35782 > OK, I am back. [Problem: over time, a batch deletion of 50 or 100 > RMAIL files takes longer and longer. This slow down only happens > after an instance of Emacs has been running for several days. New > instances are quick. Unfortunately, Emacs looks fine to me.] > Using GDB, the bug seems to be in > re_match_2_internal OK, here is some info that might help you get info that's more useful: There are several possible cases: - some code calls re_match_2_internal more often over time. I.e. the calls to re_match_2_internal do not get slower themselves, so the problem is elsewhere. - the calls to re_match_2_internal get slower for some reason. This may be because: - the regexp changes over time. - the text matched changes over time. - some side-data makes the code slower over time. Now, re_match_2_internal is a function that can easily take an insane amount of time to terminate (its complexity is exponential), depending mostly on the regexp used. It's a misfeature, but we do not usually consider it as a bug, and instead we try to avoid pathological cases. So a good thing to do is to look at the regexp that's being matched (typically: look up the backtrace to see the value of the `string' argument to search_buffer, then do "print string" and then "xstring" to see the actual string). If you don't know how to recognize regexps that can lead to pathological exponential behavior, post it here. Another good thing to do is to look at the text being matched (look at some of the char* variables). Another good thing to do is to say "finish" to let the code run until the end of re_match_2_internal. If it's immediate it means the problem is maybe not in the time taken in each call to re_match_2_internal, but rather in the number of calls. Stefan