On Tue, 4 Apr 2023 09:35:48 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> About allocation free: if the `Set` you pass in is immutable, and it is has >> a cached equivalent (or it is the same one), then no allocations occur >> (calculating the hash code does not do allocations, unless someone overrides >> hash code to do so) -- `copyOf` will not allocate anything if the `Set` was >> immutable already. >> >> 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. >> >> These allocations however will be only during application startup (when new >> combinations of pseudo classes are encountered) and the first time some >> state occurs in your application that results in a new pseudo class >> combination. The amount of allocations over the life time of your >> application (from this code) is probably around 50-100. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1161138111
