Re: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

2024-02-17 Thread Kevin Rushforth
On Thu, 15 Feb 2024 13:33:23 GMT, John Hendrikx wrote: >> John Hendrikx has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix wrong exception name in javadoc > > I think we can continue with this one, now that #1340 is done. @hjohn Please

Re: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

2024-02-15 Thread John Hendrikx
On Sun, 14 Jan 2024 14:32:49 GMT, John Hendrikx 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). >>

Re: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

2024-01-15 Thread Michael Strauß
On Sun, 14 Jan 2024 15:14:36 GMT, John Hendrikx wrote: >> If this method is not used anywhere, why do we need to expose >> `getStyleClassNames()` as new API to replace this one? I'm a bit puzzled by >> that, especially since you're saying that the API shouldn't be used. Why >> create something

Re: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

2024-01-14 Thread John Hendrikx
On Sun, 14 Jan 2024 04:20:56 GMT, Michael Strauß wrote: >> This is possible, although `List#get` would not perform too well when it is >> implemented for `FixedCapacitySet.OpenAddressed` as the array used as hash >> table in this class can have gaps (so we'd need to iterate to find the >> inde

Re: RFR: JDK-8322964 Optimize performance of CSS selector matching [v3]

2024-01-14 Thread John Hendrikx
> 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