Re: GETF Speedup?

&REST… um, sorry, I meant &KEY args, when taken along with &REST, so that I can transport all of the keyword associations in bulk.



> On Oct 12, 2025, at 07:16, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> I should point out that my interest in P-Lists stems directly from their use in &REST args of functions. If function &REST were organized like A-Lists, then I’d be more directly interested in them.
> 
> And I also suspect that this provides the impetus for high performance P-Lists in the rest of LW.
> 
> ————
> Now … interesting that you aren’t seeing the same speedup relationships that I saw on my M1. What could be different between our M1’s?
> 
>> 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). 
> 
> Arrays are not suitable for sparse collections unless you don’t mind the waste of memory space.
> 
> 
> 
> 
>> On Oct 12, 2025, at 07:04, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>> 
>> 
>> 
>>> 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
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


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