Re: GETF Speedup?

"Bradford Miller (as bradford dot w dot miller at gmail dot com)" <[email protected]>
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
I never said there was. I’m just disappointed (?) that many such LispM ideas haven’t been preserved in current platforms.

Sent from an iPad I found on the couch

> On Oct 13, 2025, at 4:05 PM, Tim Bradshaw <[email protected]> wrote:
> 
> 
> There is nothing to prevent the objects that CL calls hash tables from using a strategy like that.
> 
>>> On 13 Oct 2025, at 19:15, Bradford Miller (as bradford dot w dot miller at gmail dot com) <[email protected]> wrote:
>>> 
>> This discussion reminds me of the Symbolics “Table Management Facility” (q.v. https://www.chai.uni-hamburg.de/~moeller/symbolics-info/documentation/Symbolics-Common-Lisp-Language-Concepts.pdf ). 
>> 
>> The basic idea was you used the common lisp hash table interface in your code, and the machine would organize it for efficiency based on size (you could predeclare a size so you didn’t pay a runtime penalty for reorganization). 
>> 
>>>> On Oct 13, 2025, at 2:06 PM, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 13 Oct 2025, at 17:28, David McClain <[email protected]> wrote:
>>>> 
>>>> And now the count is down to 10 associations!!
>>> 
>>> Pretty much what Bradshaw’s tests showed. 10 key/value pairs should still be sufficient for small time dictionary storage, especially if you place frequently used items at the top of the list. 
>>> 
>>> _______________________________________________
>>> 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.