VB LookupResult allocations dominating code analysis scenarios

[sharwell]

Version Used: 15.7

Steps to Reproduce:

Run performance testing scenario #26778 on a machine with a large number of CPU cores (I used 28).

Actual Behavior:

Up to 50% of the overall allocations (30+GiB) are VB LookupResult allocations resulting from misses in the shared object pool.

🔗 #26398 contains an initial proposal for resolving this, but it did not reach a resolution.

[AlekseyTs]

@sharwell Could you check if #26845 has any effect on the scenario?

[sharwell]

@AlekseyTs I re-ran this today on a 2990wx and the result was abysmal. Cache misses resulted in allocation rates of 30GB/min (44% of total). Poor use of processor locality further resulted in burning over 1500+ CPU seconds per minute (43% of total) just on accessing this cache (i.e. 25 CPU cores were dedicated to just this cache, but at the end were still missing). This does not count any of the CPU time resulting from the increased allocations.

[AlekseyTs]

@sharwell Is there any information about specific locations where the allocations occur?

[sharwell]

@AlekseyTs

• 48% of the cache misses occur in Binder+MemberLookup.LookupInClass
• 30% of the cache misses occur in Binder+MemberLookup.LookupForExtensionMethodsIfNeedTo
• 6% of the cache misses occur in ImportedTypesAndNamespacesMembersBinder.LookupInSingleBinder
• 5% of the cache misses occur in Binder+MemberLookup.Lookup
• 4% of the cache misses occur in TypesOfImportedNamespacesMembersBinder.LookupInSingleBinder

This covers the vast majority of cases.