paulirwin opened a new issue, #1201: URL: https://github.com/apache/lucenenet/issues/1201
### Is there an existing issue for this? - [x] I have searched the existing issues ### Task description I noticed when reviewing #1200 that the [existing code (example)](https://github.com/apache/lucenenet/pull/1200/files#diff-092b352b0e745a7f63744637e0e854c22e44fe2f12624b8f95640ac0327de86cR80) sometimes uses interfaces like `IDictionary<TKey, TValue>` for the type of private fields and variables, instead of the concrete type. While this matches upstream and helps ensure you're coding to the contract rather than the implementation, this might be accidentally harming performance. By typing the field/variable to the interface, we lose out on some optimizations like how [`OrderedDictionary` uses a struct enumerator to avoid an allocation/boxing](https://github.com/NightOwl888/J2N/blob/main/src/J2N/Collections/Generic/OrderedDictionary.cs#L1373). Also, the JIT can more aggressively inline, eliminate bounds checks, vectorize, etc. when the type is concrete. Microsoft has the [CA1859](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1859) analyzer specifically to flag this, and this can be used to make finding issues and refactoring easier. Note that we should only do this for **private** fields (and potentially other private members, like return types of private methods) as well as variables, so that we are not changing the public contracts. A comment should be added mentioning CA1859, i.e. `// LUCENENET: CA1859 - Use concrete types when possible for improved performance` While there is likely benefit beyond collections, let's start small and not "boil the ocean" here. Collections are where there is the biggest benefit due to things like stack allocated enumerators and possible vectorization. I think this is worth evaluating as a deviation from exactly matching upstream Lucene code. cc @NightOwl888 for thoughts/feedback. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
