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.
Current dev build, but for a long time before that too. JDK 1.5.0 b63. I often get long delays in reaction to changes in the selection in the Projects tab. Sometimes just moving up or down ten or so nodes - esp. across multiple projects - freezes the IDE for up to ten seconds or so (!). I can watch the main window title bar repaint every second or so, while the GUI remains frozen until it is done. Taking some thread dumps, it seems most of the time is being spent in VCS methods. (I have nb_all mounted as a CVS working dir and do most of my work in that.) Note in particular that VcsFileSystem.folder seems to be running for about half of the time, which seems bizarre since really all this needs to do is the same thing LocalFileSystem.folder does - check File.isDirectory() and return that. Any access to the cache just to check if a folder is a folder is surely a bug.
Created attachment 17452 [details] Sample thread dumps (can make more if you are interested)
Beta 2 showstopper.
The cache is inefficient, it needs to be reimplemented... There is also running the "Refresh-After-WindowActivated" thread, which slows everything down. There should be no noticeable slowdown during normal work. Due to this fact this is not P1 IMO. This concrete problem can be fixed by reimplementation of VcsFileSystem.folder() method. It should first check whether the file exists. If yes, it can ask it whether it's directory, otherwise ask the cache.
Re. refresh after window activated thread - probably an artifact of my measurement: switching to an xterm window to type "killall -QUIT java" over and over. Would not be active during normal usage. Perhaps I need to do more careful measurements here (or perf team in case they can reproduce this kind of problem). Re. not checking cache when file exists - please note that I have enabled the "Hide Shadow Files" option for all my VCS mounts. This means that *every* VCS FileObject must correspond to an existing file or folder in my case.
A concrete test: on a test user dir, I open a current dev build, JDK 1.5 b63, Linux, Ocean. Mount nb_all as a CVS working dir, accept default options for it. Close Versioning tab. Open web/project and all required projects. Wait for CP scanning to finish; garbage collect. Start taking thread dumps at 0.5 second intervals. Move selection up and down across projects in the Projects tab (no project nodes expanded). Very slow reaction to changes. After a while, speeds up (and status bar shows "Command Refresh finished."). Now expand Core -> org.netbeans.core.perftool to see files within, keep on moving up and down. Slow for a while, then speeds up. Repeat with MOF Metadata Repository -> org.netbeans.modules.mdr. Thread dumps show a variety of things going on, of course, but definitely heavy VCS cache involvement. Clearly the Find action is turning itself on and off much too aggressively, also. Maybe a separate bug. Should run on some kind of slight delay to permit events to be coalesced. Also it's off that so much time is spent in Children methods, since I spent little actual time expanding nodes, and this was fast when I did it. Some bug in Children maybe?
Created attachment 17481 [details] (GZIPped) list of thread dumps at 0.5sec intervals
I filed issue #48685 re. excessive children recreation.
This is Future Q-build stopper.
I get randomly to it too on local filesystem. I think that culprit is PackageViewChildren that recursively from AWT thread lists all folders to prepare flattened package structure: at java.io.UnixFileSystem.list(Native Method) at java.io.File.list(File.java:915) org.openide.filesystems.LocalFileSystem.children(LocalFileSystem.java:147) org.openide.filesystems.LocalFileSystem$Impl.children(LocalFileSystem.java:437) org.openide.filesystems.DefaultAttributes.children(DefaultAttributes.java:175) org.openide.filesystems.AbstractFileObject.list(AbstractFileObject.java:76) org.openide.filesystems.AbstractFolder.refreshFolder(AbstractFolder.java:649) org.openide.filesystems.AbstractFolder.refresh(AbstractFolder.java:842) org.openide.filesystems.AbstractFileObject.refresh(AbstractFileObject.java:701) org.openide.filesystems.AbstractFileObject.refresh(AbstractFileObject.java:682) org.openide.filesystems.AbstractFolder.check(AbstractFolder.java:549) org.openide.filesystems.AbstractFolder.getChildren(AbstractFolder.java:197) org.netbeans.modules.masterfs.MasterFileObject.getChildren(MasterFileObject.java:232) org.netbeans.spi.java.project.support.ui.PackageViewChildren.findNonExcludedPackages(PackageViewChildren.java:164) org.netbeans.spi.java.project.support.ui.PackageViewChildren.findNonExcludedPackages(PackageViewChildren.java:171) org.netbeans.spi.java.project.support.ui.PackageViewChildren.findNonExcludedPackages(PackageViewChildren.java:171) org.netbeans.spi.java.project.support.ui.PackageViewChildren.findNonExcludedPackages(PackageViewChildren.java:171) org.netbeans.spi.java.project.support.ui.PackageViewChildren.computeKeys(PackageViewChildren.java:150) org.netbeans.spi.java.project.support.ui.PackageViewChildren.addNotify(PackageViewChildren.java:111) ....
PackageViewChildren is not to blame - you cut out the part of the stack trace that shows it being asked for its children over and over and over, for no apparent reason. That is why I filed issue #48685, q.v.
I understood addNotify() as the entry point to the deep recursion. Anyway attaching full trace.
Created attachment 17491 [details] The same on local FS (trace)
Right. The stack trace is fine - *once*. It is doing what it is supposed to be doing. If it is being called over and over, that means a performance bug in Children. Note C.getArray calling C.addNotify, which is supposed to happen only when a node is expanded.
The folder() implementation improved: /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.291; previous revision: 1.290 I've tried the test case that you described (on Windows :-( so the behavior can be a little different) and I have encountered only short occasional freezes for ~0.5s shortly after the IDE got focus. Otherwise the percieved performance seems to be acceptable. Please try again with updated VcsFileSystem. If there is some excessive call to children and associated methods, the not-optimal VCS cache impl. will only worsen the situation. So perhaps after issue #48685 is fixed, this problem will go away.
No, it's still very slow for me using VcsFS.java 1.291.
It just reminds me that I prototypely rewrote VCSFS.children() to behave like LocalFS.children(). All file hiding logic would be then addressed at UI layer by VisibilityQuery (VQ). In this case the VQ would be run only for folders. Probably not acceptable for 4.0 timeframe.
No, it's not acceptable to change the behavior of children() in 4.0. There must be added virtual files, because of associated use-cases. The VisibilityQuery is already in place instead of filtering in children. Children do not filter anything that comes from disk. It was also suggested to move this back to P2. This is not q-build stopper, but beta2 stopper. This happens likely on large projects only.
Also will need to recheck situation after fix of issue #48685.
Well fixing issue #48685 definitely makes a big difference. Leaving this open in case there is anything you want to address that is visible from the stack traces here.
The other problem seems to be in children(). This will be fixed in the future (probably promo-F, where "synchronize" action is planned and virtual files will either disappear or displayed (hopefully) by another means). But children() can be expected to be slow, since they have to consult the disk. It seems that we can not do more optimizations in 4.0, so I'm closing this as fixed (there were some partial fixes). The rest depends on cache redesign and UI spec for promo F (virtual files).