Re: GETF Speedup?

"David McClain (as dbm at refined-audiometrics dot com)" <[email protected]>
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
No, I didn’t profile anything. Just a simple quick and dirty speed test.

I did verify that the GETF test is actually scanning the list. I did that by using a smaller dimension test and printing the result of every GETF.

I suspect that the speed reason is that GETF has been improved and has only to perform #’EQ matching. GETHASH has to hash the key to find which thread of the table to scan. And then it is probably using #’EQL testing by default.

So it probably isn’t too surprising that GETHASH looses out to direct GETF on small’ish lists. The question becomes, how small. I’m showing that small is much greater than 1_000 key-val pairs.



> On Oct 11, 2025, at 04:41, Yuri Davidovsky <[email protected]> wrote:
> 
> 
> 
>> On 11 Oct 2025, at 04:27, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> I am delighted that GETF is so efficient now. It really needs to be, given functions with keyword argument lists.
> 
> Hm. Would you be able to share the test code? I wonder how that could be done given that lists have to be traversed sequentially to find the value. If anything, that could be saying that hash tables are not as fast as they probably should be, which is not good since a package symbol lookup is essentially a hash table search, as I understand it. 
> 
> Also, did you happen to profile assoc lists while at that to see how they compare to plists?


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.