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.
Time for opening java editor is quite prolonged by the Navigation view. It should try to not parse the source initially and just display "<no selection>" until clicked by the user or first node selection change (cursor move).
The problem was partially caused by the eager patch to the VisualizerNode and partially fixed by removing the patch (issue 27345). Anyway, it still takes quite long to populate the combo and it is done synchronously from inside addNotify e.g. during switching editor panes (may have something to do with editor)
Created attachment 7439 [details] Thread dump from switching between editors (>1s)
Thanks -- the culprit is Bean Patterns analyzer. The Bean Patterns node (for some reason) forces the analysis to run synchronously (again - in a different place). Will post to a request processor.
Thanks. Would it be possible to reschedule/delay the whole setting of the root node from addNotify() of the component?
Hele, I sincerely doubt that changing the NodeListModel's root node from a non-AWT thread would help: NodeListModel.setNode() does Mutext.EVENT.readAccess, so it schedules the action into AWT anyway.
/cvs/beans/src/org/netbeans/modules/beans/PatternChildren.java,v <-- PatternChildren.java new revision: 1.24; previous revision: 1.23
can I consider this fixed? Re. rescheduling: What I was talking about was scheduling the update of the root node to some later time, to allow the editor to come up and be fully rendered before the Java module starts its computations. Current (with your fix) behavious is: <user>Switch to different editor(or open new) <code>addNotify() <code> prepare navigation combo, post beans children to RP <code>starts painting <code,concurently in RP>analyze bean patterns <code,concurently in parser>parse java files(parse jar ;-) <ui>finished painting. This is: the real responsiveness impact stays the same, it is only hard to measure it now. The best scenario would be: <user>Switch to different editor (or open new) <code>addNotify() -> *post only* navigation combo update <code>starts painting <ui>finished painting. <code>parse java files(better to not have to parse jar ;-) <code>analyze bean patterns <ui>update navigation view Re. NodeListModel.setNode() vs Mutex.EVENT: Obviously it should prepare the needed data out of AWT so setNode() would be fast. Is it possible to implement my suggestions? I'll post one example of stack trace with your fix.
Created attachment 7475 [details] Thread dump with beans pattern analyzer running during the first paint.
Hmm... how do I know when the Editor window finishes painting ?
Good question ;-) Do you want a post-painting hook? My estimation is that 0.5s after addNotify should be enough for the editor to make it, but the user needs ~1s to catch up with the newly presented information anyway so what about posting the computation 1000ms after addNotify()? (Incremental UI update) If the editor takes longer than 1s to initialize/load, it will be so slow already that we'll need some wait-background-activity indicator anyway.
Whatever - just please make it a general policy, I would not like to introduce additional ad-hoc magic constants. So if the policy for displaying complex subnodes is to return {empty,waitnode} immediately and post an asynchronous update after XXX milliseconds, fine - please document it somewhere.
Editor combo works fine now [200210090100]
I'm not sure this is really fixed - for the reason Petr wrote above - the fix does not improve the responsiveness much. The impact does not seem to be so big after all (as mentioned in the issue 27710), but postponing it would help. Probably should be decided together with 27710.