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 bug was originally marked as duplicate of bug 232450, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.4 RC1 (Build 201309162201) VM: Java HotSpot(TM) 64-Bit Server VM, 24.0-b56, Java(TM) SE Runtime Environment, 1.7.0_40-b43 OS: Windows 8 User Comments: GUEST: Unbelievably Slow. Loading its first Java project after nstall Maximum slowness yet reported was 21609 ms, average is 21609
Created attachment 140350 [details] nps snapshot
one should not get all subprojects in opened project hook, OPH is under project write lock and all things happening should be fairly fast. One cannot guarantee that with subproject provider where endless lists of projects can be loaded/instantiated.
Created attachment 141108 [details] nps snapshot I was trying to build a maven project where the maven repo was not currently on the system, and the IDE tried to download the repo index.
Well, I doubt the (whole) problem lies in FoD's OpenedProjectHook. Definitely this was not the problem when FoD was introduced. But since then there has been some "simplifications" of OpenProjectList threading (by Jesse?) and they in my opinion cause these starvations. For example the slowness report https://netbeans.org/bugzilla/attachment.cgi?id=141108 attached by John Yeary does not involve FoD at all and still is able to block a call to org.netbeans.modules.project.ui.OpenProjectList.getDefault() for 132s! I don't see a reason accessing a singleton getter should block and wait for OpenProjectHooks to finish. In the original design it returned quickly list of "lazy" projects and later fired appropriate changes. Can OpenProjectList.getDefault() & co. return again quickly without blocking on projects to finish opening?
(In reply to Jaroslav Tulach from comment #4) > Well, I doubt the (whole) problem lies in FoD's OpenedProjectHook. > Definitely this was not the problem when FoD was introduced. But since then > there has been some "simplifications" of OpenProjectList threading (by > Jesse?) and they in my opinion cause these starvations. things change. I was not aware that calling FileUtil.addFileChangeListener() is also evil thing to do in AWT, but despite the name, it actually touches the disk and for some people in some situation is a problem. > > For example the slowness report > https://netbeans.org/bugzilla/attachment.cgi?id=141108 > attached by John Yeary does not involve FoD at all and still is able to > block a call to org.netbeans.modules.project.ui.OpenProjectList.getDefault() > for 132s! Oh well, the fact that the exception reporter cannot sort out slownesses correctly doesn't mean that my original evaluation is invalid. Especially when almost all exceptions logged appeared after I've reassigned the issue. > > I don't see a reason accessing a singleton getter should block and wait for > OpenProjectHooks to finish. In the original design it returned quickly list > of "lazy" projects and later fired appropriate changes. > > Can OpenProjectList.getDefault() & co. return again quickly without blocking > on projects to finish opening? never going to happen. We've had deadlocks and race conditions before that we now trade for occasional slowness (that however allows the user to continue) besides: OpenProjectList.getDefault() is never the final destination, and most methods on the singleton are protected by the mutex as well. As I've noted in other issues, one solution is to get rid of ProjectOpenedHook's current contract of write locking the project mutex, for most of the stuff done in POH it's not necessary anyway. That's why I also suggested to you what I did suggest. You don't to fix it, fine with me. Some of the other (newer) reports are duplicate of other issues that are fixed in current dev - BadgingNode.isMain() is async now. http://hg.netbeans.org/core-main/rev/c01fa5fca35d fixes a case of main project action submenu. Still I believe that striving for slim POHs (that don't perform much under write access when they don't need to, eg. in your case getting subprojects is a case for read access, not write) is also a way to make things faster in general. I'm sorry that you disagree. so this issue is partly fixed, partly duplicate of issue 192206 and other issues due to the ambiguity of slowness reporter algorithm. marking as fixed
Integrated into 'main-silver', will be available in build *201312140002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/c01fa5fca35d User: Milos Kleint <mkleint@netbeans.org> Log: #236240 in some cases, load project list off-AWT