Re: GETF Speedup?

This also speaks to alternatives to augmented or altered argument lists…

When we use &KEY args in function definitions, the behavior of Lisp ensures that if you want to change a particular argument before passing along the list, all you have to do is prefix the existing P-List with your changed key value. 

But over time, that builds up a longer and longer list with stale entries at the rear, and which prevents the GC from reclaiming storage taken by those stale args.

So, in preference to this situation, it becomes better to use REMF and (SETF GETF) on copies of the original arg list. (copies, because we are in parallel code and need reentrancy).

So I have implemented a formal Class for argument “Dictionaries” and a COPY-WITH method which provides a copy of the object along with upgraded and deleted key associations.

> On Oct 12, 2025, at 07:25, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> And to explain further, I had been in some discussions with language designers about the best way to provide argument lists to functions or in messages for Actors…
> 
> The other fellow mentioned using “Dictionaries” - which, after probing what he meant, reveals that he is a JS and JSON writer, not a Lisp person. And “Dictionaries” seem to be a prevalent mechanism, albeit a very noisy syntax compared to a P-List.
> 
> So we already have what the other fellow was talking about, but we haven’t formalized in to the same extent as JS and JSON. We just don’t see the need to be so formal about it, and we prefer a more sanguine syntax that all the excess punctuation and quoting of slot names etc.
> 
> 
> 
>> On Oct 12, 2025, at 07:20, David McClain <[email protected]> wrote:
>> 
>> &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


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