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.
It hurts startup time. The parsing can't be done during menu posting too, so it would be best to cache the result and don't parse it again and again.
I would be willing to prepare a suggested patch for this. IMHO titles should not be parsed during startup, only when the submenu is selected.
The fact that indices are created (*.html parsed) during submenu display was already reported as a performance bug.
Why? Surely if you are explicitly asking to see and perhaps select a Javadoc index, you are willing to wait a moment for the IDE to find them. It seems unreasonable to complain about that. On the other hand, we should not spend time parsing them for a user who never uses this feature.
I've filled the issue. It was slowing down invocation of the View menu (parent of the JavaDoc Indices submenu). It was slowing it every time the menu was invoked. -> cache results. It was slowing it down one level earlier -> be more lazy Anyway, the problem is it is a menu. If the parsing took 300ms, the user had to wait additional 300ms before the submenu is posted which is unacceptable according to our responsivenes goals. On the other hand, being a submenu brings some advantage, as submenu is itself posted with delay (250ms?) So probably the best would be to: *) Don't parse eagerly (no FS listener/ModuleInstall) *) Cache results (no slow subsequent menu) *) Start asynchronous parsing on addNotify() *) Wait for results in case of getPopupMenu() (user "really" want it) Looking at the original issue 28912, it seems that most of it was already suggested...
This is a P1 that by definition should be fixed for 3.5. Is anyone working on it?
"If the parsing took 300ms, the user had to wait additional 300ms before the submenu is posted which is unacceptable according to our responsivenes goals." - OK, if you say so, though I don't see that as a big problem personally. Agree with Petr's four suggestions, to which I would add that you can probably do common-case parsing much faster by directly searching for "<TITLE>", which may avoid the need to do more complicated fixes (depending on how fast access to the filesystem is, of course).
"I would be willing to prepare a suggested patch for this" Would you? (reassigned). "I would add that you can probably do common-case parsing much faster" Agreed.
Created attachment 9689 [details] Proposed source patch (trunk or r35)
Created attachment 9690 [details] Binary patch - save as $nbhome/modules/patches/org-netbeans-modules-javadoc/32551.jar
Fixed in the trunk. Petr I would appreciate a code review and verification that the overhead is gone or reduced to an acceptable level. committed * Up-To-Date 1.60 javadoc/src/org/netbeans/modules/javadoc/JavadocModule.java committed * Up-To-Date 1.53 javadoc/src/org/netbeans/modules/javadoc/search/Bundle.properties committed * Up-To-Date 1.5 javadoc/src/org/netbeans/modules/javadoc/search/IndexBuilder.java committed * Up-To-Date 1.7 javadoc/src/org/netbeans/modules/javadoc/search/IndexOverviewAction.java
patch tested on Linux. I haven't found any functionality problem of javadoc module.
Petr is not here today so he cannot do the code review. But I looked at the diff and it looks sane to me. Approved for 3.5
committed * Up-To-Date 1.59.2.1 javadoc/src/org/netbeans/modules/javadoc/JavadocModule.java committed * Up-To-Date 1.50.18.3 javadoc/src/org/netbeans/modules/javadoc/search/Bundle.properties committed * Up-To-Date 1.3.2.2 javadoc/src/org/netbeans/modules/javadoc/search/IndexBuilder.java committed * Up-To-Date 1.6.2.1 javadoc/src/org/netbeans/modules/javadoc/search/IndexOverviewAction.java
Startup time is OK, runtime performance seems OK. The only minot thing that can be improved is removing ModuleInstall from the javadoc's manifest. It wasn't here until fix for issue 28912, although the class was there for historical reasons.
JavadocModule.uninstalled() closes all outstanding open top components created by the module (see also the registerTopComponent method). IMHO this ought to be handled automatically by the window system, based on the <module> element of a .settings file computed from ModuleInfo.owns(Clazz), but I did not want to fool around with that now.
OK, I understand. Now the history (from CVS logs): 2003/02/04 fix of 28912 - the code was added to the MI, but the MI was not referenced from the manifest (from 2001/08/30, when it was removed by psuchomel) 2003/02/28 - the MI was added to the manifest but using wrong tag 2003/03/14 - the MI was really made functional. Javadoc people, what do you think about your ModuleInstall?