Avoid recreating EquivalenceKeys for usual suspects #533
Conversation
Also avoid using Objects.hash() in these critical objects as it is allocating an array. It is especially useless when computing only one element. FWIW, we got rid of it in HV a long time ago as it proved to be harmful.
|
Yeah, in the persistent index, all |
|
Also, this looks good, but as you mentioned it's just to start the discussion, I'm not merging it yet. When you feel like this is mergeable, let me know. |
@Ladicek I was wondering if there could be a way to make sure we use the instance from |
ClassTypeEquivalenceKey is extremely critical because it is used also for return types and parameters. Thus implementing a full cache makes sense. Now, I'm not sure it should be positioned here and I'm wondering if its lifecycle should be tied to the lifecycle of the overlay.
|
@Ladicek I pushed an additional commit to cache all the Ideas welcome :) |
|
I guess it should be possible to have a cache for equivalence keys in the annotation overlay. I don't think it's a good idea to keep one in the |
Yeah, I agree. I'm not a big fan of static CHM looking forward to a memory leak... Now, I'm not sure it's worth caching all the equivalence keys. In my flame graph, I have only see the primitive one and the class type one. |
|
I'm pretty sure there's a relatively small number of class types that are used most often and a long tail of class types that are used relatively infrequently. An actual cache with the size of, say, 100 or 1000 elements should cover it well, I think. |
|
On the huge code base I generated with mostly entities, repositories and REST resources, I have for
Keep in mind that the code is generated so mostly identical stuff. But I'm pretty sure in a real life code base, you also have a lot of the same classes used as parameters and return types. |
|
Also one thing that is IMHO important: in the case of I'm not sure this optimization would be as beneficial for cache entries for which the key is a lot more complex. |
|
Note that we still have the option of only using the first commit, which might be a good compromise. |
|
I've submitted #540, which is roughly the 1st commit + the 2nd commit limited to I'm not going to close this, because there's more work to do for sure. |
Also avoid using Objects.hash() in these critical objects as it is allocating an array.
It is especially useless when computing only one element but even if not it's worth avoiding the allocations. FWIW, we got rid of it in HV a long time ago as it proved to be harmful.
@Ladicek this is to start the discussion for now.
One question I had: when creating the index, do we reuse the same instance of
DotNameforString,Long... And if so, I was wondering if we could reference them somehow as I would expectequals()to be faster when most of the time we have the exact same instance (except if crafted manually and not coming from the index).