Performance issue with FLLarge FLLargeIdentityDictionary and FLLargeI…

[ELePors]

Modify references to FLLarge... to use standard Pharo objects.
Performance is increased in my tests, but i don't know the full impactof this modification ... ?

Cheers
Eric.

[tinchodias]

The change may be correct for current images.
The purpose of FLLargeIdentityDictionary was being polymorphic and faster than IdentityDictionary when a large number of key/values are stored... and it wasn't slower with small number of key/values too AFAIR.
We benchmarked on 32-bits Pharo, maybe 1.1 ?!?!
Maybe @marianopeck remembers more details.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will remain open but will probably not come into focus. If you still think this should receive some attention, leave a comment. Thank you for your contributions.

[theseion]

Please remove all custom hashed collections completely.

[theseion]

@tinchodias as far as I can tell, drawing on the benchmarks that Guille did, the custom collections no longer offer any advantages.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will remain open but will probably not come into focus. If you still think this should receive some attention, leave a comment. Thank you for your contributions.

[tinchodias]

@tinchodias as far as I can tell, drawing on the benchmarks that Guille did, the custom collections no longer offer any advantages.

Maybe after the switch from 32 to 64-bits images (or/and some other changes), the need of these large collection has disappeared, and even more now it's counter-productive. I like it if this happens, because the ode becomes easier to understand.

I suppose this means we deprecate the FLLarge* collection classes for some versions, and delete them afterwards.

[theseion]

Done for Pharo 13: eb83885.