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.
Build: NetBeans IDE 7.0 Beta (Build 201011152355) VM: Java HotSpot(TM) Client VM, 19.0-b09, Java(TM) SE Runtime Environment, 1.6.0_23-b05 OS: Windows XP User Comments: aldobrucale: Starting a java debugging session xylifyx: debugging GUEST: Opening projects after mercurial cloning. Maximum slowness yet reported was 18172 ms, average is 7346
Created attachment 105516 [details] nps snapshot
Created attachment 105525 [details] nps snapshot just cut (CTRL-C) a file
lot of dupicates -> p2
For the most recent report #541306, bug #177262 is the root cause. I can improve on things by making Maven's ActionProviderImpl always consider COMMAND_RUN_SINGLE_METHOD to be "supported", but only conditionally "enabled". That may help since StepIntoActionProvider in the debugger is checking for an unrelated action, so there is no need to do a potentially expensive check there. Report #453242, the oldest, is unrelated. In that case, something (again in the debugger) is asking for the display name of a project, which requires loading the project model. Could perhaps be fixed by making Info.getDisplayName initially return some placeholder string (e.g. directory name), then asynchronously load the project model and fire PROP_DISPLAY_NAME when ready. I would hope the debugger treemodel code would listen for property changes, but I do not know. Report #528708, in the middle, is also unrelated. Here RSMDataObjectAction is blocking on a slow impl of ActionsImplementationFactory.canRename, which I think it should not. The explorer is simply showing a context menu and needs a JMenuItem with some label, "Rename" in fact. There is no reason to do extra work unless and until this menu item is selected. Report #541304 is again unrelated - in the Hudson integration. I can fix that one. Report #540983 is in the editor - ProjectAwareCodeStylePreferences would better not be run directly from rendering. And so on. This is not really one bug, it is just a random collection of snapshots that all happen to terminate with something trying to load a Maven project model from EQ. Someone will have to go through all 160 duplicates, classify them, and file blocker bugs in the appropriate components.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/9076d76a774f User: Jesse Glick <jglick@netbeans.org> Log: #194908 (report #541306): always enable Run Focused Test, just show a warning when project setup makes it impossible.
Thanks for evaluation. Making p3 again since reports are more like distinct and not actually pointing at some high visible single problem. Duplication algorithm must be improved to prevent grouping such unrelated reports. Filed http://netbeans.org/bugzilla/show_bug.cgi?id=205282 for this.
My latest report probably belongs in junit.
Integrated into 'main-golden', will be available in build *201206260002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c0142fef8c9a User: Milos Kleint <mkleint@netbeans.org> Log: part of issue #194908 - slowness http://statistics.netbeans.org/analytics/exception.do?id=593889 just try a name that is not based on MavenProject content.
I am constantly hitting long delays that get reported under this umbrella—should probably be reinvestigated.
(In reply to comment #9) > I am constantly hitting long delays that get reported under this > umbrella—should probably be reinvestigated. if I got it right, the 2 reports filed by you are caused by SoftReferences on MavenProject being released at some point and the project reloaded from AWT's project.ui.PhysicalView$GroupNode.getName(). very little we can do there..
given that wesignificantly reduced the amount of memory ocupied by MavenProject instance for 7.3 (by clearing the caches associated with the building request) maybe we can keep on hard referencing the MavenProject instance while the project is opened. so the soft references would only get cleared for projects that are not in primary use.
http://hg.netbeans.org/core-main/rev/1f26b3b97b7b hopefully fixes some of the reports, specifically the ones filed lately by jglick). open projects hard-reference the MavenProject instance, so that it never gets released, it's required all the time anyway and is immediately recreated after GC.
Integrated into 'main-golden', will be available in build *201211080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/1f26b3b97b7b User: Milos Kleint <mkleint@netbeans.org> Log: #194908, #215352 when project is open, use hard reference to keep MavenProject always around, before it gets opened and after it gets closed, keep on using the SoftReference
*** Bug 231764 has been marked as a duplicate of this bug. ***
just a few reports since 8.0 reassigned to responsible module owners (some reports are already fixed) closing this one for now