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.
I profiled creating of popup menu for nb_all/core project's node in Projects view. I found out that during popup creation the subprojects (core/term, core/registry and core/output) are opened. See the attached OptimizeIt screenshot where you can see that AntBasedProjectFactorySingleton.loadProjects() is called 4 times (on the three directories mentioned above plus on core/build) and that this results in 3 calls to NbModuleProjectType.createProject(), for the three subprojects mentioned above. This is very expensive.
Created attachment 26289 [details] OptimizeIt screenshot
Not sure why is this filled against projects. The FileOwnerQuery is IMO required to load projects when someone asks for them. The javacvs module is asking.
Sorry, I have overseen that it goes through the GenericSources.Group.contains() at the first sight. Nonetheless, there is probably nothing projects can do with it. I think that the javacvs module should not do so much work during popup menu construction.
The contruction trace is not synchronous anymore (issue #65364). CVS action enablement logic needs to inspect project source structure. SG.contains() is needed for correct nested project handling. Otherwise user would get enabled Commit on non-modified project etc... Please optimize SG.contains().
[Please use "Reassign issue to owner of selected subcomponent" when changing component or you leave an issue assigned to a nonexistent or incorrect owner.] Don't think it is possible to optimize GenericSources.Group.contains(); cannot check whether a subdir is owned by another project other than by checking FOQ. Using PM.isProject on subdirs would not suffice since it would not take into account external source roots. Can only speed up project load time (which is already filed separately anyway); or introduce new APIs into FOQ to check explicitly whether an external owner exists for a given dir (without loading it). At any rate, once the nested projects (these are *not* subprojects, please note) are loaded, they should stay in memory for a while so not every context menu invocation need pay this price. Re. the javacvs side: 1. Just constructing the main popup menu for the project should *not* check for enablement of CVS actions, since these are in a submenu. Not sure if the profiler snapshot is showing results from when the CVS submenu is posted or not. Tonda please clarify. If any checks are being done for submenu items which are not even being made visible, that is clearly a bug in cvslite. 2. It is customary to make menu items unconditionally enabled for which a precise enablement check may be too expensive. If the user selects the menu item, just show a dialog explaining that it does not apply. In this case, if the user tries to Commit a project with no changes, just show a dialog saying there are no changes to commit. Of course, precise enablement is nice when it is feasible, but it is much less important than a responsive context menu. 3. I presume that cvslite is already doing some form of caching of status information about the project anyway, since it displays a badge on the project iff it has modifications. So, why not reuse that info?
> 1, 2 Addressed by issue #65364. > 3. I presume that cvslite is already doing some form of caching of status CVS Annotator (implements MFS.AnnotationProvider) gets set of files to annotate. This is reverse case, CVS must find out which files apply. Caching works at file level {file, status} tuples. It raises question how can project node supply files to annotate without SG.contains()?
It seems that an old build has been measured (Tonda, what was your build number, JDK, etc.), marking as duplicate of issue #67450. *** This issue has been marked as a duplicate of 65364 ***
PKuzel's integration just postponed the work via "RP.post { invokeLater () {...} }" to a later execution of the nested project opening in AWT thread. The thing here is: IF NESTED PROJECT OPENING COULD BE AVOIDED? Jesse, I discussed this with Honza Lahoda and the only way seems to be making SG.contains() cheaper by assuming that the following case is unsupported: /tmp/ProjectA |-> src/ (sources of ProjectA) |-> src1/ (sources of ProjectB, not belonging to ProjectA at all) /tmp/ProjectB If we would not support this case, the test for "being a project" could be just assuring that a directory contains nbproject/project.xml and the nested projects would not have to be OPENED in this case. What do you think about this?
A few minor comments: 1. Re "IF NESTED PROJECT OPENING COULD BE AVOIDED?": another thing I said is that javacvs is maybe doing more work than necessary, and that they probably could do a cheaper check that will not touch nested projects. 2. Please note that I gave one example why the contains method works the way it works, but there may be many more cases. 3. Please note that there is editor, editor/lib, editor/libsrc. This is not the same case (if editor project is loaded, editor/lib project is also loaded), but somehow similar.
We cannot make such a restriction now. Better spend our efforts where it belongs - making project loads quicker.
Actually I figured out a way. If ProjectManager.isProject returns true, then you can be pretty sure that a subdir is *not* contained in this project. If it is false, then you still have to check FOQ. This should preserve the same semantics while avoiding loading nested projects just for SourceGroup.contains. The only way it could differ from previous semantics is if a nested folder looks like it contains a project (e.g. has a nbproject/project.xml folder), yet that nested project cannot in fact be loaded (malformed project.xml, missing project type module, etc.) - then the previous impl would report that the folder is contained in the outer project, whereas the new impl will report that it is not. The new behavior is probably closer to what is wanted anyway.
The fix is anyway needed for the optimization in #62221 to work well: without it, if you open e.g. the ant module, a full netbeans.org scan is triggered even though ant is a stable module, because the CVS fileset for the project has to know to exclude ant/docs, which is not a stable module.
committed * Up-To-Date 1.7 projects/projectapi/src/org/netbeans/spi/project/support/GenericSources.java committed * Up-To-Date 1.2 projects/projectapi/test/unit/src/org/netbeans/api/project/ProjectUtilsTest.java
Great idea! This helps a lot. I verified the nested projects are not opened. Most of the time is now spent in the calls to isProject() and it is 1/10 of the time it took with opening the nested projects - see the OptimizeIt screenshot I'll attach.
Created attachment 26490 [details] OptimizeIt screenshot