From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Mon, 19 Mar 2018 09:43:12 -0400 Message-ID: References: > <834lldp18f.fsf@gnu.org>> <83tvtco8xl.fsf@gnu.org> <83d100nrpg.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521466912 17859 195.159.176.226 (19 Mar 2018 13:41:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2018 13:41:52 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 14:41:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1exv2p-0004Xk-H2 for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 14:41:47 +0100 Original-Received: from localhost ([::1]:42129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exv4s-00027d-Ez for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 09:43:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exv4J-00027K-5o for emacs-devel@gnu.org; Mon, 19 Mar 2018 09:43:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1exv4G-0003sP-1X for emacs-devel@gnu.org; Mon, 19 Mar 2018 09:43:19 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:35593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exv4F-0003rY-RB; Mon, 19 Mar 2018 09:43:15 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w2JDhCnq019270; Mon, 19 Mar 2018 09:43:12 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1BE4266461; Mon, 19 Mar 2018 09:43:12 -0400 (EDT) In-Reply-To: <83d100nrpg.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 Mar 2018 15:02:51 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6245=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6245> : inlines <6500> : streams <1781652> : uri <2611063> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223815 Archived-At: >> The idea is that the above loop (even if called only twice) might be >> sufficient to make line-number-at-pos take 0.2s. > I very much doubt that loop could take such a long time. I also find it unlikely. > And running a benchmark 1000 times means that the 2nd through 1000th > iteration find the mapping much faster, probably bypassing the > loop entirely. Quite likely. BTW, when thinking about how to avoid this loop's worst case (regardless if it's the source of the current problem), I was thinking that we could probably make that worst case even less likely by replacing the hardcoded "50" with a limit that grows as the loop progresses. The patch below should make sure that the total number of iterations (through markers + through chars) is no more than 2*buffer-size, no matter how many markers there are. [ Rather than incrementing by 1 we should ideally increment by a number that corresponds to how much slower is each iteration through markers compared to the iteration through chars, but I have no idea what that number would typically be. ] WDYT? Stefan diff --git a/src/marker.c b/src/marker.c index f61701f2f6..bfe6de486e 100644 --- a/src/marker.c +++ b/src/marker.c @@ -141,6 +141,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t charpos) struct Lisp_Marker *tail; ptrdiff_t best_above, best_above_byte; ptrdiff_t best_below, best_below_byte; + ptrdiff_t distance = 50; eassert (BUF_BEG (b) <= charpos && charpos <= BUF_Z (b)); @@ -180,8 +181,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t charpos) /* If we are down to a range of 50 chars, don't bother checking any other markers; scan the intervening chars directly now. */ - if (best_above - best_below < 50) + if (best_above - best_below < distance) break; + else + distance++; } /* We get here if we did not exactly hit one of the known places. @@ -293,6 +296,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t bytepos) struct Lisp_Marker *tail; ptrdiff_t best_above, best_above_byte; ptrdiff_t best_below, best_below_byte; + ptrdiff_t distance = 50; eassert (BUF_BEG_BYTE (b) <= bytepos && bytepos <= BUF_Z_BYTE (b)); @@ -323,8 +327,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t bytepos) /* If we are down to a range of 50 chars, don't bother checking any other markers; scan the intervening chars directly now. */ - if (best_above - best_below < 50) + if (best_above - best_below < distance) break; + else + distance++; } /* We get here if we did not exactly hit one of the known places.