On Sat, 8 Apr 2023 17:37:27 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>>> 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. @mstr2 I've optimized this now without the lambda as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1176095204
