From: Sebastian Sturm <s.sturm@arkona-technologies.de>
To: emacs-devel@gnu.org
Subject: Re: State of the overlay tree branch?
Date: Mon, 19 Mar 2018 00:20:13 +0100 [thread overview]
Message-ID: <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> (raw)
In-Reply-To: <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de>
for the record, I just switched back to emacs master (no noverlay) and
the time reported by (benchmark-run 1000 (line-number-at-pos (point))
increased by a factor of ~40, to 75-80s. At this level, editing is
unbearably slow. With the semantic highlighter disabled, the same
measurement yields ~2.5s (still painfully slow, but borderline usable),
so about the same time reported by the noverlay branch.
To me, this suggests that noverlay indeed improves performance, though
not necessarily to the level I had previously claimed. find_newline may
solve this particular issue completely.
Since the time taken by line-number-at-pos seems to fluctuate wildly for
(to me) unknown reasons, I'll try and see if I can set up a systematic
way to collect reliable data.
On 03/19/2018 12:03 AM, Sebastian Sturm wrote:
> concerning the performance improvement with noverlay, it seems I spoke
> to soon. I've now had the issue reappear, both with the noverlay branch,
> and with the semantic highlighter set to use font-lock. Sorry for the
> misinformation.
> Again, however, line-number-at-pos shows up as a large CPU time consumer
> in the profiler report, and benchmark-run still reports several ms per
> invocation (though this time it's usually around 2 to 4 ms instead of
> the 20 to 25 I measured earlier), so I'd still be very much interested
> in a faster line-number-at-pos implementation.
>
> On 03/18/2018 10:04 PM, Sebastian Sturm wrote:
>> I also found it surprising that overlays would slow down line
>> counting, but since I don't know anything about the architecture of
>> the Emacs display engine, or its overlay implementation, I figured
>> that overlays must be to blame because
>>
>> (i) the issue went away after switching to the feature/noverlay branch
>>
>> (ii) configuring the semantic highlighter to use its font-lock backend
>> also resolved the performance issue (though with the font-lock
>> backend, highlights are easily messed up by editing operations which
>> makes the overlay variant far more appealing)
>>
>> I also found that some other heavy users of overlays such as
>> avy-goto-word-0-{above,below} feel faster with the feature/noverlay
>> branch, so I'd welcome a merge of the overlay branch even if there was
>> a technically superior alternative to line-number-at-pos that didn't
>> suffer from overlay-related performance issues.
>>
>> That being said, your suggestion sounds intriguing. What would be
>> required to expose find_newline to Lisp? Would I simply have to wrap
>> it in one of Emacs's DEFINE_<something> macros? Is there some
>> documentation on the Emacs C backend?
>>
>> On 03/18/2018 09:39 PM, Eli Zaretskii wrote:
>> >> From: Sebastian Sturm <s.sturm@arkona-technologies.de>
>> >> Date: Sun, 18 Mar 2018 21:14:53 +0100
>> >>
>> >> [1] I'm using cquery for my C++ editing needs, which comes with an
>> >> overlay-based semantic highlighting mechanism. With my emacs
>> >> configuration, lsp-mode/lsp-ui emit 6 calls to line-number-at-pos per
>> >> character insertion, which consume ~20 to 25 ms each when performing
>> >> edits close to the bottom of a 66KB C++ file (measured using
>> >> (benchmark-run 1000 (line-number-at-pos (point))) on a release
>> build of
>> >> emacs-27/git commit #9942734...). Using the noverlay branch, this
>> figure
>> >> drops to ~160us per call.
>> >
>> > If lsp-mode/lsp-ui needs a fast line counter, one can easily be
>> > provided by exposing find_newline to Lisp. IME, it's lightning-fast,
>> > and should run circles around count-lines (used by
>> line-number-at-pos).
>> >
>> > (I'm not sure I even understand how overlays come into play here,
>> > btw.)
>>
>
next prev parent reply other threads:[~2018-03-18 23:20 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 [this message]
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
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=86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de \
--to=s.sturm@arkona-technologies.de \
--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.