all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: State of the overlay tree branch?
Date: Thu, 22 Mar 2018 09:16:16 -0400	[thread overview]
Message-ID: <jwv1sgcw94b.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: ee462718-15d8-f075-c0a5-1f8b8e8d8f61@arkona-technologies.de

> 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
> <fast.perf> <slow.perf>:

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.




  parent reply	other threads:[~2018-03-22 13:16 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-18 20:14 State of the overlay tree branch? Sebastian Sturm
2018-03-18 20:39 ` Eli Zaretskii
2018-03-18 21:04   ` Sebastian Sturm
2018-03-18 23:03     ` Sebastian Sturm
2018-03-18 23:20       ` Sebastian Sturm
2018-03-19  6:43         ` Eli Zaretskii
2018-03-19  9:53           ` Sebastian Sturm
2018-03-19 12:57             ` Eli Zaretskii
2018-03-19 14:56             ` Stefan Monnier
2018-03-19 15:07               ` Sebastian Sturm
2018-03-19 15:13                 ` Stefan Monnier
2018-03-20  1:23                 ` Sebastian Sturm
2018-03-20  6:30                   ` Eli Zaretskii
2018-03-21  0:36                     ` Sebastian Sturm
2018-03-21  6:47                       ` Eli Zaretskii
2018-03-22 13:16                       ` Stefan Monnier [this message]
2018-03-22 19:54                         ` Sebastian Sturm
2018-03-22 20:04                           ` Sebastian Sturm
2018-03-22 20:52                   ` Stefan Monnier
2018-03-22 23:11                     ` Sebastian Sturm
2018-03-23  5:03                       ` Stefan Monnier
2018-03-23 12:25                         ` Sebastian Sturm
2018-03-23 12:47                           ` Eli Zaretskii
2018-03-23 13:19                             ` Stefan Monnier
2018-03-23 13:37                               ` Noam Postavsky
2018-03-23 13:55                                 ` Stefan Monnier
2018-03-23 14:22                               ` Eli Zaretskii
2018-03-23 14:39                                 ` Stefan Monnier
2018-03-23 19:39                                 ` Stefan Monnier
2018-03-25 15:11                                   ` Stefan Monnier
2018-03-25 16:39                                     ` Eli Zaretskii
2018-03-25 17:35                                       ` Stefan Monnier
2018-03-23  8:07                       ` Eli Zaretskii
2018-03-23  9:08                         ` Eli Zaretskii
2018-03-23 10:15                           ` Sebastian Sturm
2018-03-23 12:39                             ` Eli Zaretskii
2018-03-23 12:12                           ` Stefan Monnier
2018-03-23 12:40                             ` Eli Zaretskii
2018-03-23 12:55                               ` Stefan Monnier
2018-03-19  6:36       ` Eli Zaretskii
2018-03-19  6:28     ` Eli Zaretskii
2018-03-21 14:14   ` Sebastien Chapuis
2018-03-21 15:35     ` Eli Zaretskii
2018-03-26 13:06 ` Stefan Monnier
2018-03-27 20:59   ` Sebastian Sturm
     [not found] <<c24f8534-5245-026e-da18-f6be7b9702bf@arkona-technologies.de>
     [not found] ` <<834lldp18f.fsf@gnu.org>
2018-03-18 21:37   ` Drew Adams
2018-03-19  1:33     ` Stefan Monnier
2018-03-19  6:50       ` Eli Zaretskii
2018-03-19 12:29         ` Stefan Monnier
2018-03-19 13:02           ` Eli Zaretskii
2018-03-19 13:43             ` Stefan Monnier
2018-03-19 14:28               ` Eli Zaretskii
2018-03-19 14:39                 ` Stefan Monnier
2018-03-19  6:33     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv1sgcw94b.fsf-monnier+gmane.emacs.devel@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.