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.
Created attachment 131326 [details] Loading projects blocks project browsing back trace After launching Netbeans, if I want to immediately start browsing through a project's files and get to work, I must wait for all of the projects to finish loading. This can take many minutes. In many cases, my customers might call me, and have sent me an email, just moments apart for a problem where they are getting an exception message that they want help to resolve the cause of. If I have not started Netbeans yet, I have to sit and wait for far too long, to be able to simply open a source file and use the exception backtrace line number to go to that line in the source file and survey what is happening. This is just really a giant barrier to productivity and getting work done. It seems like this is another place where meta data access is unreasonably blocking other activities in the IDE. I am not sure why it takes so long to get projects to a safe point. If I am not accessing files in the IDE for a project, it seems like the IDE should not be loading and meddling in the project's meta data. I've attached the stack trace of where the pause is occuring for me. If nothing else, it would be an improvement that if I start clicking into a project, that this project could be loaded immediately, and then all of its dependencies brought to the top of the list of things to load, if everything really has to be loaded.
Reassigning to project/Generic infrastructure
not a bug, project loading/opening is takes time. but in general not a huge amount of time unless memory heap usage is exhausted during the opening process, then GC can slow down things significantly. knowing the type of projects in use could help as well. from the stacktrace it's j2se project. Please consider reducing the number of projects opened at a time, eg by using project groups.
Alot of the projects are J2SE, some are modules, maybe one or two are test EE projects. I've also opened http://netbeans.org/bugzilla/show_bug.cgi?id=226073 to document another use of EDT for disk access activities. If you look in the attached back traces there (well I'll attach them here to for convenience), you can see that I've increased PermGen and that did help with project loading. Why are such small values chosen by default. If everyone has to change them, and users have bad experiences with the IDE because of those small values, it seems like you could record the length of time for project loading, and on the next IDE launch, if it's excessive (more than a minute), increase PermGen toward 128m, and once you get to that boundry, and startup is still slow, present the user with a message, and perhaps a link to a web page/help file that details the issues they might look at. All of my opened projects, are things that I do work on, regularly enough that I don't want to have to go chase down the project to open it up. In particular, this can lead to problems with opening old projects that are not longer active, but must be maintained on the disk for recovery of old environments during support activities.
Created attachment 131353 [details] Stack traces showing activities during project loading, including EDT being used for explicit class loading.
the AWT callstack is not project system related, should be filed separately against editor bugzilla component. AFAIK permgen setting is done in installer and not modified since. Is also not project system related and should be filed separately. I'm keeping this issue open to evaluate the need of running org.netbeans.spi.project.support.ant.GeneratedFilesHelper.refreshBuildScript on project open (locking with write mutex) in j2se projects. See first thread dump. greggwon: please note that for any serious performance evaluation we will need a profiling snapshot - http://wiki.netbeans.org/FaqProfileMeNow
>I'm keeping this issue open to evaluate the need of running >org.netbeans.spi.project.support.ant.GeneratedFilesHelper.refreshBuildScript on >project open (locking with write mutex) in j2se projects. See first thread >dump. Yes, it has to be done, it updates the build-impl.xml when the new version of the build-impl.xsl is available after project opening. From the javadoc of the GeneratedFilesHelper.refreshBuildScript: Typical usage from {@link org.netbeans.spi.project.ui.ProjectOpenedHook#projectOpened} is to call this method for both scripts with the appropriate stylesheets and with <code>checkForProjectXmlModified</code> true. Regarding the write lock. The generic project infrastructure calls the POHs under the write lock as they may do changes to project metadata. Changing this contract to no lock and requiring the client to acquire write lock itself will be a dangerous incompatible change, it will be better to create a new interface LockFreeProjectOpenHook for this. If the LockFreeProjectOpenHook is created and GeneratedFilesHelper will be rewritten to hold the write lock only for time it writes to files (not for time it do XSL transformation) it can help.
If I understand correctly, it sounds like there is a pretty large scale lock that is being held for a long time, and that creates a lack of granularity to allow other, unrelated tasks/updates to not be able to also make use of the CPU resources available. So, everyone is standing in line, instead of working independently. If there is sufficient lack of "atomic" control actually needed, so that the "LockFreeProjectOpenHook" could be possible, is there not also a more granular locking approach that could be used over all? Is there a lock manager for project locks that could just "hand out" the appropriate lock for a "project" and let code fight for access to "those locks" if there is contention, and thus greatly increase the locking granularity so that there would be far less tendency for so much code to be standing in line, waiting a turn at getting useful work done?
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss