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

[Martin Frb]

On 13/04/2025 21:37, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Sun, 13 Apr 2025, Martin Frb via fpc-devel 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.
>
> Hm. I assumed a 'Sorted' property as in TStringList,
> which should insert on the correct spot if you do an add, but 
> apparently the generic TList does not have this :-(

Sorry, I was unclear. Yes Sorted = true.

And "Sorted again" => not from scratch, rather "kept sorted", but 
keeping inserting elements into the middle of a list that size => costly.

Sorted list / bin search => lowest memory, but slower
    (so depending on capacity it can be as much as a dictionary... / and 
too low capacity makes it slower)
AVL tree => more memory (maybe can be reduced, by rewriting some of 
it...), fast
TDictionary => currently fastest, and lowest mem consumption (and 
hopefully even less mem)