Re: GETF Speedup?

> On 12 Oct 2025, at 15:24, Tim Bradshaw <[email protected]> wrote:
> 
> The behaviour of plists is interesting: I assume this is some cache in the machine.  Alists might do the same thing with a longer spine (but do not seem to).
> 
> Also below that is the same thing but for a hit at the half-way point, and first elt hit.

Very interesting indeed. I actually did not expect to see any meaningful difference between alists and plists. Recently I was contemplating using alists vs plists vs hashtables for storing http headers (dbm’s email on list lookup performance vs hash tables was rather timely) and was leaning towards alists as they seem to encapsulate the key:value nature of http headers a bit better for my liking, but it seems like plists are probably a better choice performance wise (although they make looking up several headers with the same name trickier than with alists).

On the other hand, there is typically only a dozen or so headers being sent or received at each request, so it appears either option will be faster than hashtables, however the graphs shows that plists should perform better in general case.

With that said, I am not seeing a confirmation of dbm’s statement that plists are fine for numbers of items up to a 1000, as according to the first two graphs hash tables start to take over at about 30-40 elements for plists and even less so at about 10 elements for alists.

Additionally, it appears that in all the tests the key values were rather synthetic using plain numbers (you might as well use an array and access values by their indices in such case), most likely in real word usage the keys would be symbols, or keywords (maybe strings in some cases). This will make the key comparison more time consuming for lists and hash tables with their hash calculation overhead might close the gap.




_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html