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 Dev (Build 100330-f5c1283fd15b) VM: Java HotSpot(TM) Client VM, 10.0-b19, Java(TM) SE Runtime Environment, 1.6.0_04-b12 OS: Windows XP User Comments: GUEST: You have to fix theese slowdowns, they are everywhere in every menu whenever a new menu is about to open! GUEST: IDE just finished loading GUEST: creating a new project. GUEST: Open the NetBeans IDE with RCP. Maximum slowness yet reported was 17188 ms, average is 7398
Created attachment 96353 [details] nps snapshot
Slowness #366753 is dupe of bug #175806. Slowness #351187 is mostly GUI stuff, some bug #177262. Slowness #346159 is bug #177262. Slowness #362819 is ToggleBookmarkPresenter.getToolbarPresenter. Reassigning to editor for evaluation.
#531193 is WebProject constructor WhiteListUpdater.getServerWhiteList().
(In reply to comment #3) > #531193 is WebProject constructor WhiteListUpdater.getServerWhiteList(). It is but I cannot see anything wrong there - OS filesystem seems to be very slow. All other two reports from NB 7.1 Beta are unrelated to Web Project and each is different. It is not obvious what's wrong. I would like to pass it back to statistics module to fix their algorithm for duplicates and reassign.
Report #577420 is about ProjectChooserAccessory.ProjectFileChooser.approveSelection blocking on ProjectManager.findProject - unrelated to anything else here that I know of. The duplicate detector for slowness reports is really quite useless, I think. Would be preferable to have all the reports just go into a database with no automatic BZ link, and have someone from QE periodically pick out a report more or less at random and file a bug report for it with an actual analysis.
Integrated into 'main-golden', will be available in build *201205040400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/be0dd134b91e User: Jesse Glick <jglick@netbeans.org> Log: EQ freezes opening projects from chooser. (#183192 comment #5)
107 reports => P2
org.netbeans.modules.project.ui.actions.NewFile$WithSubMenu$DynaMenu.getMenuPresenters(): 11965 / 0
QE agrees to waive it for NetBeans 7.3 with promise that we will do our best to fix it in one of the following patches. Thanks for your understanding and patience.
(In reply to comment #8) > > org.netbeans.modules.project.ui.actions.NewFile$WithSubMenu$DynaMenu.getMenuPresenters(): > 11965 / 0 unavoidable. Calls FileOwnerQuery -> projectManager to find the owning project. and that can get blocked by long Mutex.write operations. Maybe only getting rid of the popup altogether. But in general, when looking at a random sample of 10 reports coming in lately, there's no apparent reoccuring theme. The issue has 100+ duplicates only because the sorting algorithm is flawed (or less bluntly "has potencial for improvement"). the only solution solving these issues in general is not in sight, as long as there is FileOwnerQuery that can not only find loaded projects but also load those not yet touched in the current session.
the latest reports coming in are not readAccess+writeAccess blocked. The reoccurring pattern there is very slow cnd project loading (on remote fs) that is blocking other threads within the ProjectManager.findProject(). I still believe there is no panacea recipe here. Without a project system paradigm shift at least. FileOwnerQuery is the main bottleneck. As long as FOQ can effectively load projects and needs to be accessed from all possible threads (FileEncodingQuery, action enablement etc) there is no way of making AWT fast consistently. Since project infrastructure delegates to 3rd party code for project initialization, we cannot ensure that project types and other 3rd party code (remote fs) don't slow down project loading, so no matter what synchronization we apply on our code, there still will be cases that are slow. What would constitute a paradigm shift? 1. FOQ only knows about projects that were loaded previously during this IDE session. 2. optionally FOQ could report to upwards that a file belong to a project that is not loaded. Effectively we would load less projects, some behaviour could change as a result though. Project encoding and version control related actions come to mind, but there will likely be more.
(In reply to comment #11) > What would constitute a paradigm shift? > 1. FOQ only knows about projects that were loaded previously during this IDE > session. > 2. optionally FOQ could report to upwards that a file belong to a project that > is not loaded. Either would require deprecating the current API call and introducing a new one with different documented behavior. Perhaps easier to fix EQ callers to do their work asynchronously. (Already done in some cases for action enablement.) In many cases it is not just the call to FOQ which could be slow, but operations on the Project it returns.
no more slowness reports since 7.3.1 and over a year ago. Closing.