This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The listener model is suspicious of slowing down the whole IDE. Would it be possible to measure the amount of time spent in firing various events and the count of whole listeners created in the IDE? Before that we can hardly redesign things to work better and faster.
There was a discussion on nbdev which contained a lot of useful ideas: http://www.netbeans.org/servlets/BrowseList?listName=nbdev&by=thread&from=7740
I'll look at it. Measuring created events is simple, measuring fire counts is a bit harder. I can't easily measure number of listeners created as they are mostly interfaces. I think I can count attaching though/
Target milestone -> 3.3.1.
Set target milestone to TBD
More of your charter now, I guess.
Done repeatedly using various approaches. IIRC original complain was about cascading processing of events in series where we can have certain overhead to run the code to notify listeners. The bigger problem is if we are listening to inappropriate events and perform some actions when these are fired. Reasons for this can include refiring of events (some patterns of this type were fixed long time ago between DOs and node by Hrebejk for example). Another can be listening to change in activated nodes + winsys registry + editor registry. Yet another problem of heavy use of listeners is that this makes it more difficult to ensure correct lifecycle of object and sometimes we are forced to use weak listeners (more object involved, more processing to redispatch events, slower GC). Generaly observable (and usualy mutable) objects tends to live for a longer time. Representing the state of system with immutable objects means more queries to get dynamically created data and less static data with listeners attached to them.