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

[Michael Van Canneyt]

On Sun, 13 Apr 2025, Martin Frb via fpc-devel wrote:

> 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]

That seems like a more 'conventional' solution to me.

I'll leave it up to you how to enhance TDictionary using either solution...

Michael.