Performance Regression in 21 - CSS

John Hendrikx john.hendrikx at gmail.com
Mon Jan 1 15:37:34 UTC 2024


Hi,

I think I've found the issue. Note that on my machine I can't really 
reproduce the problem as clearly (Windows 10) as the performance 
degradation is not quite as bad as mentioned in the issue (maybe a 
factor of 2, and scrolling was unaffected), but it's probably what you 
are seeing as little else changed in the PR that seems to be the root 
cause.  Still, VisualVM did hint at the probable culprit 
(SimpleSelector#applies).

The problem is that BitSet (used for storing and comparing CSS style 
classes) has special logic to do fast containsAll checks if it detects 
it is compared against another BitSet. However, due to a read only 
wrapper on one of the sets this detection fails, and it will fall back 
to standard containsAll logic which is a bit slower.

The fix should be relatively trivial, and I'll create a PR soon.

I did note a few other things in my investigation:

- JFXCentral has around 1000 style classes, which means a BitSet as 
currently implemented, could use 125 bytes of memory for each 
StyleClassSet if a high bit was set
- Most selectors involve only 1 style class, sometimes 2 and rarely 3 or 
more
- Most nodes have 1 style class, sometimes 2 and rarely 3 or more

Now, if I were to implement this kind of logic knowing that the number 
of possible style classes can be quite high, and knowing that most 
selectors and nodes will rarely have 3 or more style classes assigned to 
them, I'd probably not use a non-sparse bit set as it is currently 
implemented.

I've played around a bit with a sparse bitset, and although I did not 
see amazing (overall) performance gains, the change (after applying the 
regression fix) did shave off another 10-20 ms for the "loadTimeFX" 
measurement in the JFXCentral application.

--John


On 31/12/2023 15:24, Christopher Schnick wrote:
>
> Hello,
>
> I just tested this with our JavaFX application and can confirm that 
> there are massive differences. It takes around 1-2 seconds to 
> completely apply all application stylesheets in JavaFX 20 but takes 
> around 6-7 seconds in JavaFX 21.
>
> On 12/31/2023 3:00 PM, Florian Kirmaier wrote:
>> Hi Everyone,
>>
>> Sorry for the delay - but I couldn’t find the time to extract the 
>> TestApplication for this bug.
>> Luckily, I found another application, which is also open source, 
>> which is affected by the application.
>>
>> I'm speaking about https://www.jfx-central.com/ - both the desktop 
>> and web versions are affected.
>> I’ve seen a performance deterioration of 10x when switching pages 
>> when using JavaFX21 compared to JavaFX20.
>>
>> I’ve created a ticket with further instructions on how to test it:
>> https://bugs.openjdk.org/browse/JDK-8322795
>>
>> Greetings
>>
>> Florian Kirmaier
>>
>> On Fri, 27 Oct 2023 at 21:31, Andy Goryachev 
>> <andy.goryachev at oracle.com> wrote:
>>
>>     Please create a ticket, Florian.  Would it be possible to profile
>>     the application when scrolling?
>>
>>     Thank you
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of
>>     Florian Kirmaier <florian.kirmaier at gmail.com>
>>     *Date: *Friday, October 27, 2023 at 04:20
>>     *To: *openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>>     *Subject: *Performance Regression in 21 - CSS
>>
>>     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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240101/7da9f36d/attachment-0001.htm>


More information about the openjfx-dev mailing list