Re: The overlay branch (yet again)

[Vladimir Kazanov <vekazanov@gmail.com>]

> 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 <monnier@iro.umontreal.ca> 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


--
С уважением,

Владимир Казанов