Hi Florian,
I made that change, and I'm a bit surprised it would cause any
performance regression, although I suppose it's possible.
There are a few things that could be the culprit;
1) BitSet before often ignored certain operations if the Collection
provided wasn't of the same class; ie. if you called
removeAll/retainAll/addAll with something that isn't the same BitSet
subclass, it would simply ignore the operation completely. This is
against the Set contract and would mean that doing an operation with say
a user provided list of entries (which is just an ArrayList or HashSet)
would simply not work. These operations are now no longer ignored, and
could perhaps take up some time to process -- it's possible that two
sets of different types were mixed in (FX) code somewhere that before
simply did nothing, but now actually started to work as it should,
uncovering perhaps a bug in a different area.
2) BitSet#hashCode could be somewhat slower. Before it was hashing the
results of the internal bitmap (which violates the Set contract as
that's specified as the sum of the hash codes of the entries contained
within); now it is doing the correct operation, but perhaps slower than
needed as it creates an Iterator.
As BitSets are indirectly exposed in several public API's as
"java.util.Set", they must adhere to the Set contract.
I can't really tell which one of these it could be without some more
investigation. If there is any way I can reproduce this locally, or if
you could provide more information where the performance degradation is
located (perhaps by attaching VisualVM and getting me a call stack where
performance has regressed) I can investigate further and provide a fix.
--John
On 27/10/2023 13:20, Florian Kirmaier wrote:
Hi everyone,
I've noticed that some parts of one of my applications is
significantly slower with 21. It's fast with 20.
The application heavily uses (and reuses) TextFlow with a Cell pattern.
When I scroll, it is smooth with 20, but has big freezes with 21.
I've tried all the commits that happened in between, and pin-pointed
it down to the following:
ticket: https://bugs.openjdk.org/browse/JDK-8304959
PR: https://github.com/openjdk/jfx/pull/1070
commit:
https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1
According to the description and the discussion in the PR - this
wasn't supposed to change any performance.
Is this regression known?
Otherwise, I should create a ticket for it.
Greetings Florian
