From: Vladimir Kazanov <vekazanov@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
Subject: Re: The overlay branch (yet again)
Date: Tue, 3 Dec 2019 20:46:40 +0000 [thread overview]
Message-ID: <CAAs=0-0wvxo_rK56UsNRbN6TgVUo8PVwkz9b1D7Nms8pJaJzNg@mail.gmail.com> (raw)
In-Reply-To: <jwvy2vtwbjh.fsf-monnier+emacs@gnu.org>
> 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
--
С уважением,
Владимир Казанов
next prev parent reply other threads:[~2019-12-03 20:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 14:44 The overlay branch (yet again) Vladimir Kazanov
2019-12-03 15:35 ` Vladimir Kazanov
2019-12-03 15:58 ` Eli Zaretskii
2019-12-03 16:06 ` martin rudalics
2019-12-03 16:21 ` Vladimir Kazanov
2019-12-03 17:58 ` Stefan Monnier
2019-12-03 20:46 ` Vladimir Kazanov [this message]
2019-12-03 22:43 ` Stefan Monnier
2019-12-04 11:41 ` Vladimir Kazanov
2019-12-05 14:13 ` Vladimir Kazanov
2019-12-05 15:14 ` Eli Zaretskii
2019-12-05 15:31 ` Vladimir Kazanov
2019-12-05 16:38 ` Eli Zaretskii
2019-12-06 6:48 ` Vladimir Kazanov
2019-12-09 8:10 ` Vladimir Kazanov
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='CAAs=0-0wvxo_rK56UsNRbN6TgVUo8PVwkz9b1D7Nms8pJaJzNg@mail.gmail.com' \
--to=vekazanov@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rudalics@gmx.at \
/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.