On Sat, 8 Apr 2023 17:33:46 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Perhaps write some code to show what you mean here? > >> I could cache the hash code for the sets that are returned here (they are >> immutable sets returned by `Set.copyOf` -- I checked their code, and they >> don't cache the hash codes). That would however only help if you often pass >> in a set that is already cached, to find out if you got the same one. >> Perhaps this happens a lot, I could test that. > > That's what I meant to say. It seems like an easy win to cache the hash code > of immutable sets if those same immutable sets can concievably be passed into > this method quite often. > Allocations only occur in two cases: > > * When the set you pass in is not immutable, and it is a new set that wasn't > cached yet. A copy is made (allocation) and a `Map.Entry` is created > (allocation) > * When the set you pass in is immutable, but wasn't cached yet. No copy is > needed, but still a `Map.Entry` is created. This method will allocate on every single call because it captures the method argument in a lambda object (but it doesn't need to, it can be written in a way that doesn't use capturing lambdas). That's another easy win to be had if this method is called often. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1161138414
