all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: tomas@tuxteam.de
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Should `get-file-buffer' be implemented in Elisp?
Date: Mon, 17 Jul 2023 19:48:00 +0200	[thread overview]
Message-ID: <ZLV+0CNkZjwsyR0j@tuxteam.de> (raw)
In-Reply-To: <87r0p6zy25.fsf@localhost>

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

On Mon, Jul 17, 2023 at 09:28:50AM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Sun, Jul 16, 2023 at 08:19:10PM +0000, Ihor Radchenko wrote:
> >
> > [...]
> >
> >> scenarios. And in general lookup as well as hash tables start to
> >> outperform alists just at 20-30 elements [1]
> >
> > For me, it's more like 45-ish:
> 
> Right. The link I provided actually also mentions similar number.
> 
> > How many people around here have regularly 1000 buffers?
> 
> Well. Check out https://github.com/org-roam/org-roam
> People routinely deal with thousands of buffers there and complain about
> that.

Oh, I see. The exciting thing about Emacs is that it has so many
different usages :-)

(I seldom surpass 10 or 12 buffers, FWIW).

> I also did a benchmark for opening several thousands of files in Emacs
> and the performance was quite disappointing. (Though, admittedly, not
> because of `get-file-buffer').

Yes, it would be interesting to know which part the lookup plays
in the grand scheme of things.

> > And even at 100, the absolute time is rather negligible. Somewhere
> > near 5000 buffers my (not very fast) machine reaches the 100ms
> > area for alists and lingers in the 2ms area for hashes (that would
> > be where I'd start worrying).
> 
> 100ms is fast when you do it once. But `get-file-buffer' may be called
> rather frequently by `with-temp-buffer'. 

Yes. I don't know about the original benchmark you quoted, but mine
is extremely "synthetic" and therefore full of lies: the alist gets
allocated in a tight loop and might show an unusual locality of
reference, as far as lists go. OTOH, if you are shuffling heavy
data structures in between lookups, the bigger hash structure might
compete for low level caches. On the third hand, the bad locality
of a "naturally grown" list might play havoc with TLB. And so on.

The only real measure would be to measure how much of the perceived
latency in org-roam is actually attributable to the lookup :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

      parent reply	other threads:[~2023-07-17 17:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-16 18:40 Should `get-file-buffer' be implemented in Elisp? Ihor Radchenko
2023-07-16 18:51 ` Eli Zaretskii
2023-07-16 19:05   ` Ihor Radchenko
2023-07-16 19:10     ` Eli Zaretskii
2023-07-16 20:19       ` Ihor Radchenko
2023-07-16 23:28         ` Po Lu
2023-07-17  5:06         ` tomas
2023-07-17  9:28           ` Ihor Radchenko
2023-07-17 13:11             ` Eli Zaretskii
2023-07-17 17:48             ` tomas [this message]

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=ZLV+0CNkZjwsyR0j@tuxteam.de \
    --to=tomas@tuxteam.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --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 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.