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.
Development build #200210170100 of NetBeans 4.0 Windows 2000 with FCS build #21 of JDK 1.4.1 Description: ============ It is incredible how Generic VCS mounting wizard is terribly slow. I am sure it seriously violates responsiveness guidelines, because profile selection takes 100% CPU for about 30 seconds. Please take a look at the thread dump and CPU consumption graph attached. Steps to reproduce: =================== 1. Invoke "Versioning|Mount Version Control|Generic VCS". 2. Select "CVS (Windows NT/2000)" profile. 3. The IDE gets irresponsive for about half a minute.
Created attachment 7692 [details] Graph of CPU consumption.
Created attachment 7693 [details] Thread dump taken during profile selection process.
This is performance issue.
This issue has appeared as soon as openide was splitted into the deprecated part and the rest. The problems is in the reading of commands from the SystemFileSystem. The commands are in XML file. Thus I suppose, that the problem is either a classloader problem or a performance problem in XML (DOM). Tomas, can you please try to investigate where the problem is?
Adding Jesse on cc. Perhaps he can have an idea what's wrong, because this has happened right after the merge of openide split into the main trunk.
Looking at the thread dump, I don't see anything that would obviously be related to the openide split. Anything is possible, but I have no ideas. BTW for heavy CPU bugs like this, taking one thread dump is not so useful. Take ten, spaced out a second apart, randomly. Consider the active thread. Delete the longest common suffix in the stack trace. The last line is then the point where something is going into a loop, perhaps. Look at that code.
But Jesse, is it really necessary if the bug is 100% reproducable ?
Look at VcsUtilities.getBundleString(String,String), line 466 where NbBundle.getBundle(...) with TopManager.currentClassLoader() as parameter is called. The problem is that: 1) TopManager.currentClassLoader() does not return the same instance for each call now, 2) the classloader is used by ResourceBundle to cache bundles already loaded. The result is that the bundle files are loaded again and again for each request of a string. And there are rather big number of such requests during "profile selection" (I see 646 invocations of VcsUtilities.getBundleString in profiler).
Thank you very much Tomas ! Martin could this be addressed soon ? It is really pain to mount anything ...
"TopManager.currentClassLoader() does not return the same instance for each call now" - this is true. It was never documented exactly when it would, i.e. in 3.4.: "The classloader may change from call to call, as it is affected by module and repository operations. The returned classloader will reflect the current state of the filesystem, taking into account modifications of .class files." which just says that it might change, not when it will not change. However if it would be useful to have it retain the 3.4 behavior - do not change unless some file was really modified - this can be implemented without too much work, I think. File an issue if you want this. Anyway currentClassLoader and the current API of NbClassLoader will become deprecated in 4.0 because they do not work correctly with the Java class path. 4.0-projects-compliant modules will need to use a different API anyway.
Thanks Tomas and Jesse for analysis of the problem! I need to access resource bundles located on SystemFileSystem. Probably the system class loader would be better for that purpose. Is it better to use (ClassLoader) Lookup.getDefault().lookup(ClassLoader.class) ? Or should I traverse the SFS and find the appropriate FileObject??
The default ClassLoader gives access to resources in modules, not the system file system. If you are not loading classes, just accessing resource bundles, just using FileObject would probably suffice, if you do your own caching. ResourceBundle/NbBundle does automatic locale searching, though. You can use new NbClassLoader(new FS[] {Repo.gD().gDefFS()}) And keep the classloader around between calls, to avoid thrashing the cache. You would then need to determine how to invalidate the classloader at the right times. org.netbeans.core.ClassLoaderSupport from release34 gives a hint how to do this. (Actually I think it was buggy - it only refreshed after *.class changes, whereas ResourceBundle caching would require refresh after *.properties changes too. Ideally a replacement for currentClassLoader in the Classpath API should have some protected boolean isCached(String resource) to make this configurable.)
Fixed in the main trunk. /cvs/vcscore/src/org/netbeans/modules/vcscore/cmdline/ExecuteCommand.java,v <-- ExecuteCommand.java new revision: 1.51; previous revision: 1.50 /cvs/vcscore/src/org/netbeans/modules/vcscore/util/VcsUtilities.java,v <-- VcsUtilities.java new revision: 1.24; previous revision: 1.23 I reset the classloader on every change, thus it returns updated resource bundles as well.
Verified in development build #200211080100 of NetBeans 4.0.