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