search

jtmueller / Collections.Pooled

Fast, low-allocation ports of List, Dictionary, HashSet, Stack, and Queue using ArrayPool and Span.
MIT License
538 stars 47 forks source link

I see non generic IDictionary implemented. Would you accept pull do drop it? #4

Closed dzmitry-lahoda closed 5 years ago

dzmitry-lahoda commented 5 years ago

I see next

* Adding non-generic IList to PooledList

So there is reason to add this stuff? I feel that having non generic interfaces may preclude some fancy type based optimizations in future. I have never ever used non generic list as it is not type safe either.

I do not say that it will work or case to consider, but I now experimenting with JIT of static class per generic parameters which can be used for adhoc optimization and per type combination cache. Other generic options may go from safe usage of Unsafe. And why would I use non generic API to make things slower?

jtmueller commented 5 years ago

I don't have much use for non-generic interfaces either, but I changed my mind about removing them. It's really not any extra effort to support them since that support is already present in the code I'm basing this stuff on in corefx. Supporting the non-generic interfaces makes it possible to use these collections with legacy API's that don't support generics. Having explicit interface implementations but not using them doesn't hurt performance in any way I can imagine. It makes for a DLL that's 1-2 KB larger than it would otherwise be, and that's about it. Unless there's a specific, provable scenario in which removing support for non-generic collection interfaces improves performance, I'm not really seeing a compelling case for doing so.