On Mon, 2 Mar 2020 08:31:47 GMT, dannygonzalez <github.com+6702882+dannygonza...@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? > >> 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 did start to look at why there were so many change listeners unregistering > but felt that would take a deeper understanding of the architecture and > design decisions of JavaFX scene graph and I didn't have that time to invest. > I do know that there are thousands of them unregistering in a TableView and > unregistering them is a bottleneck for the JavaFX thread. > > There are multiple change listeners on a Node for example, so you can imagine > with the number of nodes in a TableView this is going to be a problem if the > unregistering is slow. > > To get our application usable I profiled the code and saw this unregistering > as a major bottleneck, hence why I looked at this more obvious solution. > > I'm happy to look at the problem from the other angle and happy to listen to > suggestions from people with more experience of the design and architecture > but tackling the problem from the perspective of re-architecting the > behaviour of listeners in the scene graph would be more work than I could > feasibly take on. @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. ------------- PR: https://git.openjdk.java.net/jfx/pull/108
