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