[fpc-devel] RFC: Improvements for TDictionary and other hash containers
    Martin Frb 
    lazarus at mfriebe.de
       
    Thu Apr  3 13:52:22 CEST 2025
    
    
  
On 27/03/2025 12:28, Martin Frb wrote:
> There are 2 features, I am missing.
I did a couple of experiments... Those are not finished code. They only 
showcase the ideas, and only for the one OpenAddressingLp case
https://gitlab.com/martin_frb/fpc-src/-/compare/main...rtl-gen-opt?from_project_id=28644964
Would like to get opinions, if this can be included.
1) "Rehash"
This has a minor speed up effect.
It depends on the resize stepping (usually very few resizes), and cost 
of recomputing the known hashes.
2 / 3)  TryAdd / AddOrSetValue
This has a noticeable impact on performance, if running those in a loop.
- The hash does not change by a resize/rehash, so don't recompute it
- if there is no rehash then the bucketindex is known, and does not need 
to be found a 2nd time
It needs clean up, currently its 3 times the same code.
- If the new "DoAdd" are called, then all inherited classes must be 
fixed up, as they get bypassed otherwise.
- I didn't want to forward several small steps to virtual (none 
inline-able) methods, hence the copied code. But there may be a better way
4)  GetOrAddMutable
Just an extension, like AddOrSetValue.
Having it as one call, avoids recalculating the hash/index.
5) TryGetEqualKey
That is a bit special.
I have a case where
- I store object instances. (custom IEqualityComparer getting hash of 
instance content)
- I then later have another instance that may be equal (by content) to 
an existing instance (but new memory alloc)
- I want to find the original
Currently I need to
TDictionary<TMyClass, TMyClass>
Storing the identical instance pointer as key and value.
Obviously that doubles memory usage (twice the amount of pointers).
    
    
More information about the fpc-devel
mailing list