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.
This is a highly visible usability problem. When you go to "now->JSP&Servlet" the next level menu shows "empty" for anywhere from 5 to 10 seconds. This is not only a long time to wait when you know that it will eventually work, but could easily confuse new users.
Our opinion is that while this is a regression, it is not a showstopper. However, we think it is a higher priority than 3, so I'm increasing the priority and reassigning it to Petr.
To a significant degree, this is caused by the fact that many classes are loaded into the VM while the menu is being displayed. My investigation has shown that anywhere between 250 and 600 classes are loaded by the menu. Considering that loading one class takes about 10ms on average, this contributes something between 2.5 to 6 seconds to the menu display. Some more detailed information about the impact: - Displaying the menu is the worse the first time. When the menu is opened for the second time (and more), performance is better. - Bad performance will mostly affect users who do not work with JSPs. For those who do (and have, say, a JSP opened in the editor), the IDE will have already loaded many of the classes when the menu is displayed. - The regression against FFJ 3 is caused by the fact that the menu has been flattened, thus more objects are present at the top level. The fix for this issue is non-trivial. It would require rearchitecting big parts of the web application support, and perhaps even parts of the IDE core.
Waiver approved in May 9 meeting.
It looks that core team has already improved it. Can we check how it behaves in trunk now? Any hints how to improve performance on our side?
The only thing that the IDE does for displaying your templates is recognizing your templates as regular DOs If you make the recognition part more lightweight, i.e. you'll do about nothing in your DOs constructor (not touching other classes from it), it should sped up both popup creation and explorer folder expansion.
Set target milestone to TBD
Requesting waiver for NB 3.4 release. Fixing this bug would require a significant rework of the base data objects used by WebApps. This is a risky change and would delay the release.
waiver for 3.4 approved
I am not sure I agree with leaving this bug in the release, IMO this is very significant and highly visible regression, which users (wspecially new ones) are likely to hit. I have seen not response to Petr's comment about making the recognition process simpler, can you comment on that?
Further investigation has revealed several reasons for the poor performance, several of which have been already fixed, so performance has improved (see below). Secondly, this bug was filed against FFJ 4, which has more functionality than NetBeans 3.4, and contributes to the slower response time. So for NB 3.4 the problem is not that significant. Also, it was discovered that the old implementation of the looks API, which is used by the JSP object, contributes significantly to the performance problem. This API is not maintained any more, so this problem can not be remedied. Here are the results of the investigation: 1) The JSP object uses a preliminary implementation of the Looks API to create the display. It turns out that this version of Looks is very slow, and accounts for a large portion of the time spent in the initialization of the New menu. In total, org.netbeans.modules.web.core.jsploader.JspDataObject.creat eNodeDelegate() takes 878 ms. org.openidex.nodes.looks.CompositeLook.readPropertiesFromXM L() takes 250 ms, as some XML parsing is going on org.openidex.nodes.looks.Look.isLookStandalone() takes 162 ms, does more XML parsing The solution is to use the newest version of the Looks APIs do the measurements again, and give performance feedback to the openide/core team. 2) Constructor of class org.netbeans.modules.web.dd.editors.DDPropertiesLook initializes properties bundle, takes 129 ms. Easy fix, will fix. ----> Done 3) The tag library object reads the whole tag library and parses it when its node is created, which takes 827 ms. I will talk to Simran about possible fixes to this. 4) Class org.netbeans.modules.html.HtmlDataNode loads a properties bundle during class initialization: 18 ms. Easy fix. ----> Done 5) org.netbeans.modules.web.core.jsploader.JspLoader.createMul tiObject() creates the JSP editor (17 ms) and also other cookies. This should be lazy, I will fix this. 6) Class org.netbeans.modules.web.config.ConfigDataObject loads its data from the file in its constructor: 7 ms. This may not be worth fixing if the effort is too high, but I will talk to Damian about this. 7) org.netbeans.modules.html.HtmlDataObject creates its cookies at creation time, by initializing them lazily some time could be saved. ----> Not really true, no change needed. 8) org.netbeans.modules.web.context.WebAppLoader.handleFindDat aObject() takes 74 ms. This is the infamoust Web Context stuff that we want to throw away so much. This is not at the top of my priority list, but we will want to fix this if the other changes are not sufficient. 9) org.netbeans.modules.web.context.WebAppNode.getDisplayName () takes 45 ms, but we probably can't do much about that. Still, I will look at it. 10 ) org.netbeans.modules.web.context.WebAppBrokenObject$2.run () takes 150 ms, again this is Web Module code that will hopefully be replaced by Projects.
I am not sure what the next step is here...
Can we remove waiver keywords? Decreasing priority - it is not so visible now after we removed cascading menu. OTOH we need to make expanding in NFT wizard as fast as possible. I will try to implement Tim's hack. If it helps it might be contributed to next release
waiting for Tim's patch
This depends on 28623 tha won't be ready for NB3.5 so I suggest to move tagret milestone. Should not be a big problem as the impact is now limited due to changes in New from template action.
postponed for next release
Note that there is different UI and webapp templates are categorized now. I measured it on my notebook (2GHz, 1GB, Linux, JDK1.4.2_03) and get 314/299ms for JSP&Servlet node expansion in new from template wizard for 1st use with no webapp stuf initialized. Not optimal yet but acceptable - now it is comparable with XML category.
The expansion now feels reasonably fast, so marking as fixed.