[fpc-devel] Who maintains TDictionary? // Re: RFC: Improvements for TDictionary and other hash containers

[Martin Frb]

When the mailer decides to sent....

On 13/04/2025 21:17, Martin Frb wrote:
> On 13/04/2025 20:43, Michael Van Canneyt via fpc-devel wrote:
>>
>> But why don't you simply use a TList<TRange> with your custom comparer ?
>> You can then use List.BinarySearch() and retrieve the existing TRange 
>> at once?
>>
>> Your solution seems quite hackish to me. So if you really need it in 
>> TDictionary, make it protected as you indicated...
>
> Because there may be several 10000 entries (ok extreme case, I get 
> 40000 entries, after scanning several 100 files).
>
> And entries are added over time.
> When adding a new entry, the list must be sorted again. That is the 
> slow part.
>
> The old code used an AVL tree.
> That is fine.
> But uses more memory, that the TDictionary (even with the double 
> pointer storage).

> AVL tree, needs Left/rigt/balance, and because the range is not 
> inheriting
there is a separate node instance.

Of course the dictionary varies depending on the amount of empty slots.


If keys could be accessed by index (the internal slot), the
TDictionary.IndexOfKey
and
TDictionary.Keys[idx]

would do