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: Thu, 22 Mar 2018 09:16:16 -0400 Message-ID: References: <834lldp18f.fsf@gnu.org> <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de> <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> <83vadso9ad.fsf@gnu.org> <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> <83po3zmf6o.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521724741 7493 195.159.176.226 (22 Mar 2018 13:19:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2018 13:19:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 22 14:18:57 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 1ez07N-0001nR-0p for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2018 14:18:57 +0100 Original-Received: from localhost ([::1]:60784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez09Q-0001B0-CR for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2018 09:21:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez04y-0006eJ-5r for emacs-devel@gnu.org; Thu, 22 Mar 2018 09:16:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ez04v-0002lA-01 for emacs-devel@gnu.org; Thu, 22 Mar 2018 09:16:28 -0400 Original-Received: from [195.159.176.226] (port=35673 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ez04u-0002iv-OI for emacs-devel@gnu.org; Thu, 22 Mar 2018 09:16:24 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ez02o-00050H-ND for emacs-devel@gnu.org; Thu, 22 Mar 2018 14:14:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 55 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:zjKNBKNy+3G8RRtduUFdeyc2p1E= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:223914 Archived-At: > this is the profiler report I get for the slow case (BTW, is there a way to > have the profiler resolve functions within line-number-at-pos? It should do that without you asking. I mean, it won't show you `goto-char` and `point-min` kind of things since these are "inlined" (actually turned into their own byte-code), but `count-lines` should definitely be there. > - let 18368 86% > line-number-at-pos 18348 86% It's very odd that there's no `count-lines` down here (and `count-lines` is a perfectly normal Elisp function that's not inlined or otherwise treated specially), since it should be where most of the time is spent! If we assume the code works as intended, it would imply that the time is not spent in `count-lines` but elsewhere, e.g. in `goto-char`. > with perf, the ("self") time taken by buf_charpos_to_bytepos increases from > ~60% (fast case) to >98%. This is the diff generated by perf diff > : So I guess that could be it: the (goto-char opoint) spends an inordinate amount of time in buf_charpos_to_bytepos. Could you try the patch below, to see if it makes a difference? Stefan diff --git a/src/marker.c b/src/marker.c index 7773c4fce0..3d808fd6fa 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 = distance + 10; } /* We get here if we did not exactly hit one of the known places.