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.goryac...@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-r...@openjdk.org> on behalf of
    Florian Kirmaier <florian.kirma...@gmail.com>
    *Date: *Friday, October 27, 2023 at 04:20
    *To: *openjfx-...@openjdk.java.net <openjfx-...@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

Reply via email to