From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14786: 24.3.50; `field-end' is now very slow Date: Fri, 5 Jul 2013 10:06:41 -0700 (PDT) Message-ID: References: <<029969a6-cd0e-45c9-b778-57b5daf98c2a@default>> <<8338rtyp0y.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1373044075 21034 80.91.229.3 (5 Jul 2013 17:07:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2013 17:07:55 +0000 (UTC) Cc: 14786@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 05 19:07:54 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uv9U9-00013P-W0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2013 19:07:54 +0200 Original-Received: from localhost ([::1]:54286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uv9U9-0006vG-He for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2013 13:07:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uv9TM-0005qq-8V for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2013 13:07:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uv9TK-0001AX-HJ for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2013 13:07:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uv9TK-0001AM-DR for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2013 13:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Uv9TJ-00078N-Kl for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2013 13:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jul 2013 17:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14786 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14786-submit@debbugs.gnu.org id=B14786.137304401527394 (code B ref 14786); Fri, 05 Jul 2013 17:07:01 +0000 Original-Received: (at 14786) by debbugs.gnu.org; 5 Jul 2013 17:06:55 +0000 Original-Received: from localhost ([127.0.0.1]:60648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uv9TC-00077j-2l for submit@debbugs.gnu.org; Fri, 05 Jul 2013 13:06:54 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:31412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Uv9TA-00077R-2i for 14786@debbugs.gnu.org; Fri, 05 Jul 2013 13:06:52 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r65H6jQr015986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jul 2013 17:06:46 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r65H6iCM002952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 17:06:44 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r65H6hKW005801; Fri, 5 Jul 2013 17:06:43 GMT In-Reply-To: <<8338rtyp0y.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:75957 Archived-At: > > The result appears after a few seconds (I'm guessing about 4 sec > > in the directory I used). > > > > Do the same thing in previous Emacs versions (including as recent > > as 24.3, at least), and the result appears immediately. >=20 > Not exactly immediately, but approximately 4 to 5 times faster. OK. I was describing the user experience. Less than a second is quick enough for a large Dired buffer. Four seconds it not. > The problem is that dired-details floods the Dired buffer with > overlays. When there are so many overlays, searching for an end of > a non-existent property takes a lot of time, because Emacs needs to > examine every overlay in the buffer. OK. > What happened between Emacs 24.3 and the current trunk is that the > call GET_OVERLAYS_AT (XINT (position), overlay_vec, noverlays, NULL, 0); > in get_char_property_and_overlay got roughly 4 to 5 times slower. I > don't know why this slowdown happened, but it just moved the time > needed by field-end from below the annoyance threshold to well above > it. I agree with your characterization in the last phrase. > If someone can find out why GET_OVERLAYS_AT is now slower, we could > see if that could be fixed. But it's quite possible that the change > which caused that fixed some bug that we don't want to re-introduce. > In any case, I think having so many overlays in a buffer is asking for > trouble. Agreed, in general. Emacs does make heavy use of overlays here and there, and I don't see that possibility disappearing. I hope this bug (performance regression) can be fixed. It is not particular to dired-details.el, though that is one place that it can easily be noticed. For my info: When such a code change is made, is there no log of the reason behind the change? If it was to fix a bug, for instance, wouldn't that bug # be noted?