On Thu, 4 Jan 2024 14:23:14 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > I just scrolled quickly through the changes and left some comments, > > If deprecation for removal is part of the PR the consequences will need to be > discussed. Are the for-removal classes and methods not widely used? > As @nlisker notes, the implications of any deprecation will need to be > discussed. In particular, we need to consider what the consequences are for > existing applications. If any of them might be used by apps, then simple > deprecation (rather than deprecating for removal) might be best. The methods cannot be reached easily even though they are public. It would involve creating a `Selector` using `Selector#createSelector`, and then casting it to `SimpleSelector` to get access to its public methods that are not inherited from `Selector`. `SimpleSelector` itself does not have a public constructor, and the type `SimpleSelector` is not returned anywhere directly (it is always just `Selector` in the public API). The only use of one of the deprecated methods is to allow access for the internal class `SelectorPartitioning` which indeed does an `instanceof` to reach it. The other method is not used anywhere, and seems to have been an attempt to make the selectors available in the same form as you'd find them on nodes `Styleable#getStyleClass` (which is a `List`), but is hard to reach (probably an oversight that it got exposed in the final API). Google searches turn up no hits in 3rd party code for either of these. I've posted on the mailing list to discuss it further. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-1877986349
