[Cuis-dev] Small dictionaries

[Luciano Notarfrancesco]

However, in a modern VM with PICs you end up doing a sort of “linear
lookup” most of the time, even if method dictionaries are normal
dictionaries, right? A PIC is implemented as a list of comparisons? I might
be completly wrong, I don’t really know the details about how the VM works…

On Tue, Jan 13, 2026 at 01:09 Jan Vraný <Jan.Vrany at labware.com> wrote:

> On Mon, 2026-01-12 at 21:19 +0700, Luciano Notarfrancesco wrote:
> > Great to know! I think you mentioned this before… you used it for method
> > dictionaries, right?
>
> Yes, except in case of MD this was merely to keep the full lookup in the VM
> simpler and more independent of the rest, assuming this is fairly rare not
> to
> matter much.
>
> > I’ll make a note to look into this further, because in
> > modern computers it might have less of an impact, I should do benchmarks.
> >
> I'd think on modern computers it'd be even more pronounced as the gap
> between
> CPU and memory speeds widens so every cache miss is becoming more of a
> pain.
> Of course all this assumes all the code is properly jitted.
>
> Jan
>
> >
> > On Mon, Jan 12, 2026 at 21:01 Jan Vran <Jan.Vrany at labware.com> wrote:
> >
> > > On Mon, 2026-01-12 at 10:35 -0300, Juan Vuletich via Cuis-dev wrote:
> > > > Hi Luciano,
> > > >
> > > > On 2026-01-12 4:52 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> > > > > In the software Im currently programming Im using the events
> > > > > subsystem a lot, and Im subclassing from ActiveModel. Each model
> > > > > typically only triggers 2-3 types of events, so the action
> dictionary
> > > > > is very small. And I have another similar case with a small
> dictionary
> > > > > (also typically 2-3 entries, at most 5). Lookups and event
> triggering
> > > > > happen at about 300 Hz. Im wondering, wouldnt be more efficient to
> > > > > just use arrays and a linear lookup instead of dictionaries? Or,
> has
> > > > > anyone implemented dictionaries optimized for a small number of
> > > > > entries? Any advice?
> > > > >
> > > > > In general, I think we dont have models that trigger many different
> > > > > types of events, so it seems this optimization could be used in
> > > > > ActionModel. But perhaps it hasnt been a priority to optimize this
> > > > > because we dont usually fire events at high rates, I guess.
> > > > >
> > > > > Thanks,
> > > > > Luciano
> > > >
> > > >
> > > > I think such optimization would belong in Dictionary. I mean, if a
> > > > Dictionary is small, it could use an alternative lookup method if
> that
> > > > improves performance. Having a different class would make use way
> more
> > > > complicated, and we'd need to keep an eye on whether we're using the
> > > > correct kind (small / large) all the time.
> > > >
> > > > Still, I doubt there would be any performance improvement.
> Especially in
> > > > IdentityDictionaries where the hash and equality are both quick
> > > > primitives, it looks like it would perform the same as today.
> > > >
> > > > Some benchmarking is in order, if you want to investigate.
> > >
> > > I did the benchmarking in the past. Expecially for small identity
> > > dictionaries
> > > it made a difference.
> > >
> > > It makes sense. If you organize small identity dictionary as a an
> array of
> > > alternating key/value, then you can squeeze 4 elements into a single
> > > cacheline.
> > >
> > > In that respect, the traditional smalltalk dictionary implementation
> using
> > > an
> > > array of associations is somewhat suboptimal. Simply one big array or
> > > having two arrays one with keys and other with values seems more
> > > cache-friendly.
> > >
> > > Jan
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Juan Vuletich
> > > > http://www.cuis.st
> > > > http://github.com/jvuletich
> > > > http://researchgate.net/profile/Juan-Vuletich
> > > > http://independent.academia.edu/JuanVuletich
> > > > http://patents.justia.com/inventor/juan-manuel-vuletich
> > >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260113/1ccfcff7/attachment-0001.htm>