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.
There is a significant startup slowdown caused by the automatic expansion of the folders, which were expanded at the last IDE run, right at startup. I measured 30 seconds versus 24 seconds if the expansion is done right at the moment when main window is being painted versus if the expansion is done lazily after startup finishes.
The code which does the automatic expansion is in org.netbeans.modules.project.ui.ProjectTab.readExternal(in). I tried delaying the following code selectPaths( selPathsFinal ); btv.expandNodes( exPathsFinal ); but was not successful yet with finding a good approach. Delaying with RP is too aggressive.
The scalability is very bad. For example, in the extreme, when you open all NB projects and expand them all you get over 10 minutes for the startup. :-O Temporarily fixing this by disabling the automatic expansion of the previously expanded nodes in Explorer. Checking in ProjectTab.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/ProjectTab.java,v <-- ProjectTab.java new revision: 1.20; previous revision: 1.19 And now we want to run profiler and find out what this is all about... Keeping this issue open.
This might be the problem reported by participants of 40cat. Some of them reported very significant slowdown of startup and we didn't know how to reproduce it.
Please, ask those users to test the behavior of q-build, when we announce the q-build to them, to verify that this is what they encountered. Thanks. (in the q-build the IDE will always start with collapsed Explorer)
It was NetCAT for 4.0 where users were complaining about it and it's over long time. So far nobody complained in current NetCAT 4.1, but we can announce it if there will be complaints again.
Oh, I see. Thanks.
Fixes of issues 56285,56288,56290 helped quite significantly. I measured two scenarios and compared times of builds from March/10 and March/22 on my slow testing W2K machine (PIII 800MHz, 512MB). 1) extreme scenario - all Netbeans projects open and all their packages expanded in Projects view March/10 - average at 11:30 min March/22 - average at 6:30 min -> 43% improvement in the complex startup 2) small scenario - jEdit project open, package org.gjt.sp.jedit expanded, 10 files open in editor March/10 - 33.8s, 34.1s, 33.7s - average at 33.9s March/22 - 32.3s, 32.2s, 31.3s - average at 31.9s -> 6% improvement in the complex startup
I remeasured complex startup and now the difference in the case of jEdit project, org.gjt.sp.jedit expanded and 10 files open in editor is +12% for the automatic expansion. Not sure, if we want to turn the automatic expansion at start back on, or not. It still may be a problem for users which have a ton of packages expanded (see my measurement in the last comment above).
We decided that we keep the expansion restoration after startup turned OFF. A property was introduced (netbeans.keep.expansion) which can be used via -J-Dnetbeans.keep.expansion to turn the restoration of expansion ON. Downgrading this issue to P3.
Ok, I agree with that solution, maybe it could be more "open" if we had been asking for waiver (at least because it would go through NetCAT4.1) ;)
*** Issue 58616 has been marked as a duplicate of this issue. ***
*** Issue 59284 has been marked as a duplicate of this issue. ***
*** Issue 59300 has been marked as a duplicate of this issue. ***
*** Issue 65044 has been marked as a duplicate of this issue. ***
*** Issue 67031 has been marked as a duplicate of this issue. ***
>> Not sure, if we want to turn the automatic expansion at start back on, or not. It still may be a problem for users which have a ton of packages expanded (see my measurement in the last comment above). << Tonda, thanks for the measurements. I see there is really big problem with slow startup when folders are automatically expanded. You wrote that when you switched this expansion off, the IDE started faster. I don't know how to solve this problem in a different way, but this approach is not definitely best solution from UI point of view - if the folders were expanded at last IDE run, these folders should be expanded after new startup as well.
> this approach is not definitely best solution from UI point of view - if the > folders were expanded at last IDE run, these folders should be expanded after > new startup as well I see your point, but from performance perspective this is a big problem. How about the solution I told you about - adding an option "keep expansion of tree in Projects view after restart" which would be turned off by default?
>>adding an option "keep expansion of tree in Projects view after restart" which would be turned off by default << IMO, this solution is not good as well. If you put the switch into Options dialog, everybody, in case they find the switch, will switch it on, but then they will be experiencing performance problems so probably they will switch it off again (in case they know, that slowing of startup is because they checked the option on). IMO, the performance should not be increased at the expense of not expanding the folders in Project view – as you can see from related issues, the users want the IDE to persist the state they worked in last time, after new startup. Tondo I see your point as well, but from UI point of view, there should not be the option for switching automatic expansion on/off in the Options dialog. CC'ing Jano, if he has different opinion than me or wants to add something.
Just make the option have a disclaimer (if there is a significant performance issue). I really don't understand why there should be such a performance issue. I'd like to see this in 5.0.
I disagree with introducing a new UI option to pretend we fixed this problem. From UI standpoint the explorer should be expanded. We can't force the user to make a decision between faster startup and expanding the tree. It would be a very poor workaround of performance problem. I'm a bit lost in the performence numbers mentioned in this issue. Please provide meassurement for a real life example of a few projects open (or JEdit is fine) with a few packages expanded (10?). What is the performance impact (seconds, percents) of expanding the tree in such scenario? And also, how did it perform in previous release?
*** Issue 70104 has been marked as a duplicate of this issue. ***
*** Issue 59206 has been marked as a duplicate of this issue. ***
*** Issue 69123 has been marked as a duplicate of this issue. ***
*** Issue 72742 has been marked as a duplicate of this issue. ***
*** Issue 78522 has been marked as a duplicate of this issue. ***
*** Issue 9310 has been marked as a duplicate of this issue. ***
*** Issue 87350 has been marked as a duplicate of this issue. ***
netbeans.keep.expansion does not work in the favorites view on NB 5.0
netbeans.keep.expansion has no effect on the Favorites tab since this is implemented differently from the Projects and Files tab, but it would be possible to make them consistent if there is sufficient interest. Has anyone considered restoring the expansion state in a low-priority background thread after startup? This would still make the IDE feel a bit laggy until everything was expanded, but it might not prevent you from working on other things. (Personally I would not want this "bug" to be fixed and I hate having open files reopened after I shut down, at least in the case that an hour or more has passed since the last session. If I have closed the IDE and left it closed for a while, then start it up again, I am very likely working on something else anyway. Emacs and Gnome both give you the option of saving and restoring sessions, but this option is off by default. Firefox will reopen tabs from your last session if it crashed, but this is a different matter, and NB fails to save any window state whatsoever if it crashes.)
Fixing this issue after "lazy project loading" has no sense. Imagine that your IDE starts, you can do what you want and suddenly after few tens of second your explorer starts to expand automatically and randomly jump around. The UI effects would imho be undesirable. Personally, I use "Ctrl+1" from editor to open the explorer if I really need it.
Agreed.
I just wanted to report the issue of the IDE not preserving the Project tree state. Now I understand why, however what you seem to have done years ago is not a fix, it just looks like one. Now the IDE starts up faster, however I will spend more time manually opening the tree. Worse, it needs my attention, while the IDE starting up does not. How about having at least the main project open automatically and the others remembering their state so that by opening the root element the project would completely open restoring to its previous state? That could be a better compromise, because the current situation really takes a lot of the _users'_ time _after_ start up.
*** Bug 181971 has been marked as a duplicate of this bug. ***
Please reevaluate this given its continuing popularity; though I too personally find it useless, many people clearly do not find C-S-1 to be an acceptable workaround. I made some fixes in core-main #ea35420f8840 so it works correctly with lazy projects. I do not know what benchmark you were using and thus what "startup" consists of; if lazy projects were a "solution" to slow startup, then reenabling expansion mode will not harm "startup time", since it happens after the main window has been shown and lazy projects have been initialized. Obviously it means a bit more time before the CPU is quiescent and the IDE is really usable, but this is a tiny fraction of the time users would spend manually expanding the same nodes. By the same argument, restoring open files only "slows down startup" insofar as you are not considering the effort to reopen the same files by hand. The important question in either case is how often the user _wants_ the same files open, or nodes expanded, vs. wishing to start from a clean slate. HIE opinion has consistently been to restore a state as close as possible to that in effect when the IDE was last shut down. (In reply to comment #31) > Imagine that your IDE starts, you can do what you want and suddenly after few > tens of second your explorer starts to > expand automatically and randomly jump around. This is not in fact what happens. The folders are expanded as soon as possible, within a couple of seconds of everything appearing. You would not be able to do any actual work before this happens anyway.
Integrated into 'main-golden', will be available in build *201004170515* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ea35420f8840 User: Jesse Glick <jglick@netbeans.org> Log: Fixed up impl of -J-Dnetbeans.keep.expansion=true (#55701). Had been broken by lazy projects and perhaps other changes.
Use OpenProjects.getDefault().openProjects().get() http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-projectuiapi/org/netbeans/api/project/ui/OpenProjects.html#openProjects() instead of following, please: LAZY: while (true) { 1.82 + for (Project p : OpenProjectList.getDefault().getOpenProjects()) { 1.83 + if (p instanceof LazyProject) { 1.84 + LOG.finer("encountered lazy projects..."); 1.85 + try { 1.86 + Thread.sleep(1000); 1.87 + } catch (InterruptedException ex) { 1.88 + Exceptions.printStackTrace(ex); 1.89 + } 1.90 + continue LAZY; 1.91 + } 1.92 + } 1.93 + break; 1.94 + }
(In reply to comment #37) Done in core-main #767cbbdbb280. Assigning back to you to comment on whether this is going to count as a startup regression and whether it matters.
The implementation of -J-Dnetbeans.keep.expansion=true is fine, and it is not going to slowdown start. From performance point of view, -J-Dnetbeans.keep.expansion=true can be the default. The problem however is not performance, but the UI. The expansion is going to happen some time "later". Meanwhile the user can work with Project tab and expand/collapse it manually. How the user will feel if the tree is magically changed under the hood?
Integrated into 'main-golden', will be available in build *201004200200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/767cbbdbb280 User: Jesse Glick <jglick@netbeans.org> Log: Simplified way of waiting for lazy projects to load. (#55701)
core-main#4419104b9725
(In reply to comment #39) > The expansion is going to happen some time "later". In my experience it was essentially part of startup, i.e. you could not really have been doing anything before it happened anyway: the splash screen disappears, the main window appears, your files appear in the editor area as "Loading...", the Projects tab is visible, the editor shows content and its caret starts blinking, project nodes are expanded, menus render menu items with the correct height and contents, scanning begins, and in a few moments your CPU calms down and normal work is possible. > Meanwhile the user can work with Project tab and expand/collapse it manually. Looks like your check of BeanTreeView.isExpanded in 4419104b9725 will avoid the problem of a user who eagerly begins navigating in the Projects tab the moment the main window appears, even while the disk is still thrashing away and much of the GUI is laggy. Anyway, I guess it is up to UI people to look at this in realistic cases and see if it is desirable.
Integrated into 'main-golden', will be available in build *201004210200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4419104b9725 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #55701: If user does not touch ProjectTab nodes after start, then they are going to be expanded and selected to their shutdown state
I don't think bugzilla is the right place for arguing about personal UI experience. However should you ever need "netbeans --open my.nps" while knowing that previously you left some netbeans.org project open, then you'd appreciate that the UI is not blocked until apisupport.project finishes its enormous and long initialization tasks.
*** Bug 171918 has been marked as a duplicate of this bug. ***
*** Bug 89840 has been marked as a duplicate of this bug. ***