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.
Hi, I tried to fix a bug http://www.netbeans.org/issues/show_bug.cgi?id=11965 and followed last Jesse's description. That means I have build ant -Dmodules=ant,apisupport,apisupport/lite,jarpackager,openidex,utilities run IDE with runide.sh -J-Dorg.openide.loaders.FolderInstance.Services=-5 when it started I mounted netbeans.org CVS as local filesystem and then went to ant/build.xml, right clicked and tried to execute test target. As soon as I opened the last submenu data loaders started to recognize objects on the disk, even I do not know why. Looks like something triggered the recognizing process and it goes forever. If you can please investigate a bit soon, the bug can be anywhere.
I've looked into this and here are my findings: 1. The processing is not infinite. 2. The biggest problem is the File flushing while logging heavy traffic events. So, what happens: Right-click - something cause a change event that in turn cause refresh of all active DataObject (!!! about 600 of them are active after startup with standard module set !!!) Refresh involves asking for files MIME type, which does lookup for all MIMEResolvers, which involves several [before|after]Lookup calls which are logged and causes flushing of ide.log (i.e. about 600-800ms per one MIME resolution) 600files * 10x[before|afterLookup] * (60ms each flush) takes 7min Without the logging turned on, one MIME resolution takes some few millis and thus is not noticeable by the user. One would say: "Close as invalid now!", but that's not this case. There is a problem with lookup: When somebody holds a Result, he awaits that allInstances() would be quite fast and strightforward, but it in reality involves several beforeLookup, afterLookup and so on. Why when the result didn't changed? Or should everybody hold its own listener on Result and its own instances Collection, and reset it whenever change event comes? It is way more effective with current implementation.
It seems to be the thing that caused huge slowdown of opening folders in Explorer. Recognizing a file used to take about 500us, but the MIMESupport.findMIMEType(FileObject) takes around 7ms itself on the same configuration. Marking as P1 and updating title.
Exchange of bugs with Yarda.
The problem is in poor implementation of FolderInstance.instanceFinished () method. But how do you Petr measure the time?
Improved 20times. Hopefully enough.
x
Resolved for 3.4.x or earlier, no new info since then -> closing.