Re: GETF Speedup?

Here’s the source code for the simple minded test. 

SBCL 2.5.9 performs better than LWM on the tests, and does especially well on the Red-Black Tree data structures (the MAPS). Just leave out the MAPS clauses to test against Hashtable and Property lists alone.

#F is just Comer’s reader macro for (OPTIMIZE (SPEED 3) (SAFETY 0) (FLOAT 0)).

I have my Lispworks and SBCL both accepting embedded #\_ in numbers, for improved readability. Advice patches can be made available.



(defun tst (&key (nel 20) (niter 1_000_000))
  #F
  (let* ((keys (loop repeat nel collect
		     #+:LISPWORKS (lw:mt-random (* 5 nel))
		     #-:LISPWORKS (random (* 5 nel))
		     ))
         (vals (loop repeat nel collect
		     #+:LISPWORKS (lw:mt-random 1000)
		     #-:LISPWORKS (random 1000)
		     ))
         (queries (loop repeat niter collect
			#+:LISPWORKS (lw:mt-random (* 5 nel))
			#-:LISPWORKS (random (* 5 nel))
			))
         (ht   (make-hash-table))
         (lst  (mapcan 'list keys vals))
         (map  (maps:empty)))
    (loop for key in keys
          for val in vals
          do
            (setf (gethash key ht) val)
            (maps:addf map key val))

    ;; --------------------------------------------
    ;; HT - minor amount of allocation, no page faults, no GC, 20 ms
    (print "Timing HT")
    (time (dolist (query queries)
            (gethash query ht)))

    ;; --------------------------------------------
    ;; LST - no allocation, no page faults, no GC, 3 ms
    (print "Timing Lst")
    (time (dolist (query queries)
            (getf lst query)))

    ;; --------------------------------------------
    ;; MAP - lots of allocation, 38 page faults, no GC, 2449 ms.
    (print "Timing Map")
    (time (dolist (query queries)
            (maps:find map query)))
    ))

(tst :nel 1000)


> On Oct 11, 2025, at 04:41, Yuri Davidovsky (as work at disclosure dot ie) <[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