[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The overlay branch (yet again)
From: |
Vladimir Kazanov |
Subject: |
Re: The overlay branch (yet again) |
Date: |
Tue, 3 Dec 2019 20:46:40 +0000 |
> Also, I hope the new code can capture some of the insights learned along
> the way, and the design choices, e.g. in the form of comments describing the
> various performance aspects that were considered (complexity of
> `make-overlay`, `delete-overlay`, `overlay-start`, `overlays-at/in`,
> `previous-char-property-change`, of updating overlays in response to
> buffer text modifications, ...).
Do mean something like inline comments for functions accessible from
Emacs Lisp? I'll try to do my best. But it'll take some time before I
will fell comfortable with the new implementation. This time around I
want to proceed in small steps: merge tests -> untangle/clarify
internal overlay apis -> replace the lists (with the code Andreas
built, hopefully).
> Also, some performance tests would be great. IIRC a few months ago
> someone here posted some simple tests showing some percentage
> improvement in some cases, but there has to be situations where the new
> code is massively faster (after all, the new code uses a different data
> structure specifically to change the algorithmic complexity of some
> operations). It's quite possible that those situations don't "occur
> naturally" in current code, but it should be possible to trigger them in
> artificial but realistic situations (maybe changing font-lock to use
> overlays instead of text-properties, or forcing nhexl-mode to nhexlify
> eagerly the whole buffer, I don't know).
I found at least three performance comparisons Andreas provided when
discussing his implementation:
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00488.html
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00598.html
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00736.html
Notice how in the second message he provides a couple of nice
realistic examples.
But I don't think I saw (I'll have to recheck as I wasn't looking) any
benchmarking code in the branch. Anyways, It'll take some time for me
to reach that point.
> But merging the tests into `master` would be a great first step.
Indeed.
On Tue, Dec 3, 2019 at 5:58 PM Stefan Monnier <address@hidden> wrote:
>
> >> > Given that nobody replied to my original email I assume everybody is
> >> > busy with the new release.
>
> Not exactly with the new release, but yes your message fell into the
> "todo" black hole, sorry :-(
>
> >> > Is anybody interested in me doing this work?
> >> I definitely am interested.
>
> Me too.
>
> > But Andreas almost made it! So I want to reuse some of that massive
> > effort: merge tests at the very least, untangle overlay code a bit and
> > - hopefully - replace those linked lists.
>
> Yes, please!
>
> Also, I hope the new code can capture some of the insights learned along
> the way, and the design choices, e.g. in the form of comments describing the
> various performance aspects that were considered (complexity of
> `make-overlay`, `delete-overlay`, `overlay-start`, `overlays-at/in`,
> `previous-char-property-change`, of updating overlays in response to
> buffer text modifications, ...).
>
> Also, some performance tests would be great. IIRC a few months ago
> someone here posted some simple tests showing some percentage
> improvement in some cases, but there has to be situations where the new
> code is massively faster (after all, the new code uses a different data
> structure specifically to change the algorithmic complexity of some
> operations). It's quite possible that those situations don't "occur
> naturally" in current code, but it should be possible to trigger them in
> artificial but realistic situations (maybe changing font-lock to use
> overlays instead of text-properties, or forcing nhexl-mode to nhexlify
> eagerly the whole buffer, I don't know).
>
> But merging the tests into `master` would be a great first step.
>
>
> Stefan
>
--
Yours sincerely,
Vladimir Kazanov
--
С уважением,
Владимир Казанов
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/03
- Re: The overlay branch (yet again), Eli Zaretskii, 2019/12/03
- Re: The overlay branch (yet again), martin rudalics, 2019/12/03
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/03
- Re: The overlay branch (yet again), Stefan Monnier, 2019/12/03
- Re: The overlay branch (yet again),
Vladimir Kazanov <=
- Re: The overlay branch (yet again), Stefan Monnier, 2019/12/03
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/04
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/05
- Re: The overlay branch (yet again), Eli Zaretskii, 2019/12/05
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/05
- Re: The overlay branch (yet again), Eli Zaretskii, 2019/12/05
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/06
- Re: The overlay branch (yet again), Vladimir Kazanov, 2019/12/09