On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg <faste...@openjdk.org> wrote:
>> Hmm .. personally, I would consider changing such a basic (and probably >> highly optimized) implementation used all over the framework is a very high >> risk change that at the worst outcome would detoriate internal and external >> code. So before going that lane, I would try - as you probably have, just me >> not seeing it :) - to tackle the problem from the other end: >> >>> I know that in our application, the **thousands of listeners** >>> unregistering when using a TableView was stalling the JavaFX thread. >>> >> >> .. sounds like a lot. Any idea, where exactly they come into play? > >> >> >> I think that a starting point would be to decide on a spec for the listener >> notification order: is it specified by their registration order, or that is >> it unspecified, in which case we can take advantage of this for better >> performance. Leaving is unspecified and restricting ourselves to having it >> ordered is losing on both sides. > > technically true - but the implementation was linear with a fixed sequence > since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans > properties, even exposed as api to access the array of listeners). So > technically, we could go the path of explicitely spec'ing that the order is > unspecified. Pretty sure that doing so and implementing it will break tons of > application code that's subtly relying on fifo notification (f.i. register > before or after skin has its own is a simple wide-spread trick) .. which all > did it wrong and might deserve it ;-) But then if even internal code does it > .. In use cases where a large number of listeners are being discarded, it may be better to first consider changing the design to receive event notifications on nodes whose listener registrations are not frequently discarded. ------------- PR: https://git.openjdk.java.net/jfx/pull/108
