From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Helmut Eller <eller.helmut@gmail.com>
Cc: Pip Cet <pipcet@protonmail.com>,
Ihor Radchenko <yantar92@posteo.net>,
emacs-devel@gnu.org
Subject: Re: Markers in a gap array
Date: Thu, 18 Jul 2024 16:46:04 -0400 [thread overview]
Message-ID: <jwvr0bqa30h.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87v81455iw.fsf@gmail.com> (Helmut Eller's message of "Wed, 17 Jul 2024 18:48:07 +0200")
> The current scratch/igc branch, configured with MPS and -O2
> -fno-omit-frame-pointer:
>
> | test || tot avg (s) | tot avg err (s) |
> |------------------------++-------------+-----------------|
> | bytechar || 12.11 | 0.18 |
> | bytechar-100k || 12.38 | 0.17 |
> | bytechar-100k-nolookup || 9.14 | 0.22 |
> | bytechar-100k-random || 271.52 | 14.27 |
> | bytechar-100k-rev || 12.38 | 0.24 |
> | bytechar-10k-random || 38.08 | 1.43 |
> | bytechar-1k-random || 14.95 | 0.48 |
> | bytechar-nolookup || 8.97 | 0.12 |
> |------------------------++-------------+-----------------|
> | total || 379.53 | 14.36 |
>
> and without MPS:
>
> | test || tot avg (s) | tot avg err (s) |
> |------------------------++-------------+-----------------|
> | bytechar || 11.42 | 0.03 |
> | bytechar-100k || 11.48 | 0.02 |
> | bytechar-100k-nolookup || 9.15 | 0.00 |
> | bytechar-100k-random || 16.39 | 0.02 |
> | bytechar-100k-rev || 11.48 | 0.02 |
> | bytechar-10k-random || 11.97 | 0.02 |
> | bytechar-1k-random || 11.56 | 0.01 |
> | bytechar-nolookup || 9.13 | 0.04 |
> |------------------------++-------------+-----------------|
> | total || 92.58 | 0.06 |
>
> So the weak vector doesn't compare very well to the linked list.
Hmm... I wonder why there is such a large difference for markers created
in a random-order compared to the cases where they're created beg-to-end
and end-to-beg. My crystal ball is of no help but suggests that it
might hint at the fact that it's probably a silly effect that could be
fixed easily once diagnosed.
> Maybe because the vector only grows and never shrinks.
But why would that only show up when the order is random?
> The idea with the sorted markers in a gap array would probably avoid
> the worst of this.
You could try porting the code in `scratch/markers-as-gap-array`.
I haven't touched it recently, but IIRC the code itself is in reasonably
good shape: the commits themselves need to be improved (better
commit messages, maybe sliced differently) and there's a bit of cleanup
needed around the pdumper code, but it should be reliable enough.
[ I'm still not completely sure if it's a good idea, tho: I mean, I like
the idea, but the benchmarks aren't very compelling (they're not bad,
but they're not very enticing either). ]
Stefan
PS: BTW, apparently I was confused about XEmacs' markers, they don't use
a gap-array but a doubly-linked list. They use a gap-array for the
extents (where we use a fancier balanced tree instead).
Also they don't use markers to convert bytes<->chars.
Instead they keep a (per buffer) cache in an unsorted array of 50 pairs.
Surprisingly their markers store the bytepos rather than the
charpos, so `marker-position` always needs to convert to charpos and
`set-marker` does the other conversion.
next prev parent reply other threads:[~2024-07-18 20:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 4:59 Markers in a gap array Stefan Monnier
2024-07-04 10:24 ` Ihor Radchenko
2024-07-04 13:16 ` Stefan Monnier
2024-07-04 14:30 ` Ihor Radchenko
2024-07-04 20:11 ` Stefan Monnier
2024-07-04 20:34 ` Pip Cet
2024-07-04 20:42 ` Stefan Monnier
2024-07-17 16:48 ` Helmut Eller
2024-07-18 20:46 ` Stefan Monnier [this message]
2024-07-26 19:48 ` Helmut Eller
2024-08-05 19:54 ` MPS: marker-vector (was: Markers in a gap array) Helmut Eller
2024-08-05 21:14 ` MPS: marker-vector Pip Cet
2024-08-06 6:28 ` Helmut Eller
2024-08-06 6:51 ` Gerd Möllmann
2024-08-06 14:36 ` Pip Cet
2024-08-06 16:15 ` Helmut Eller
2024-08-06 3:59 ` Gerd Möllmann
2024-08-06 6:02 ` Helmut Eller
2024-07-04 22:24 ` Markers in a gap array Stefan Monnier
2024-07-07 12:31 ` Ihor Radchenko
2024-07-07 13:09 ` Konstantin Kharlamov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvr0bqa30h.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=pipcet@protonmail.com \
--cc=yantar92@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).