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.
This bug was originally marked as duplicate of bug 202490, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE Dev (Build 20120314-df69c2e22bf3) VM: Java HotSpot(TM) Client VM, 22.1-b02, Java(TM) SE Runtime Environment, 1.7.0_03-b04 OS: Linux User Comments: jglick: Opened var/log/BaseBuildableProject.dump in editor and tried to scroll it. Has long lines such as "classPath: ...". Maximum slowness yet reported was 10385 ms, average is 10385
Created attachment 116734 [details] nps snapshot
org.netbeans.spi.debugger.ui.EditorContextDispatcher$EditorLookupListener.reAttachFileChangeListener() 99.96219 10273 ms (100%) 10273 ms 1 calls org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.removeFileChangeListener() 99.96219 10273 ms (100%) 10273 ms 1 which results in at least four calls to org.netbeans.modules.masterfs.filebasedfs.utils.FileInfo.isDirectory() 99.59184 10235 ms (99,6%) 10235 ms 4 I don't think there is much to do about this in filesystems. If the debugger can move all the re-attaching the listener outside of AWT, it would be the simplest solution.
It looks unfortunate to me, that computeChildren(true) touches disk. Add/remove listener is a disk operation now, which is not expected at all. The fix is going to be dirty. :-(
Fixed by changeset: 216610:a5dabbd9e00f http://hg.netbeans.org/main/rev/a5dabbd9e00f
*** Bug 240144 has been marked as a duplicate of this bug. ***