[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