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.
Build: NetBeans IDE Dev (Build 100422-577952f4f3c3) VM: Java HotSpot(TM) 64-Bit Server VM, 14.3-b01-101, Java(TM) SE Runtime Environment, 1.6.0_17-b04-248-10M3025 OS: Mac OS X Maximum slowness yet reported was 39550 ms, average is 10698
Created attachment 97946 [details] nps snapshot
this report has almost 300 dups to date... It appears to have been introduced around April 21, 2010...
Just submitted another slowness report: http://statistics.netbeans.org/analytics/exception.do?id=399097. According to the generated .nps snapshot the reason is calling - org.netbeans.modules.tomcat5.util.TomcatUsers.createUser() in the EDT when registering a new Server instace, which calls - org.openide.xml.XMLUtil.write() and at the end blocks the UI in - java.util.zip.ZipFile.open[native]() IMO the Tomcat user should be created lazily outside of the EDT, if possible.
I've run into this problem in both 6.9 RC1 and RC2. In a free-form project, editing a JSP hangs every few seconds for 10-15 seconds. On a fresh launch of NB, first file opened being the JSP (part of a fairly large project), it begins hanging immediately after just a few keystrokes. Since I reported this about an hour ago for the second time (Report #168378), there's already been 6 more reports made. I don't know about the others, but 6.9 is going to be useless to us with this problem unresolved. Please consider taking a look at it before release.
This bug collects lots of unrelated slowness reports. I've found two related to hanging JSP editor and filed a new bug 187337.
452 duplicate ... very probably most of the unrelated .. but we need to do something about it, at least improve infrastructure to divide it automatically and correctly
It looks like org.netbeans.api.progress.ProgressUtils.runOffEventDispatchThread() does not work well with TimableEventQueue, since no slowness reported should be reported in situations, when ProgressUtils.runOffEventDispatchThread() is running. Jardo, can you take a look. Thanks.
Does not affect releases. Slowness detector in such case starts only after 20s and that none of the reports here is longer than 20s.
Let's forget the old reports and let's concentrate on the new ones. Looking at http://statistics.netbeans.org/exceptions/exception.do?id=526964 it seems that org.netbeans.modules.php.smarty.SmartyPhpFrameworkProvider$1.run() calls about 33 times org.netbeans.modules.php.smarty.SmartyPhpFrameworkProvider.locatedTplFiles() which in turn checks some mimetype of about 60 files. Using org.netbeans.api.progress.ProgressUtils is probably not the best method to signal to user such a heavyweight I/O load. Consider doing this kind of scan on background, possibly as soon as PHP project is opened, etc.
Thanks for your advice. This should be already resolved since I replaced FileUtil.getMIMETypeExtensions and comparing extensions with FileUtil.getMIMEType(fo, mime). After last measuring and I got ~250ms for php project consist of whole media wiki (about 1GB sources) - before that it was ~20s. Marking as duplicate of issue #201743. *** This bug has been marked as a duplicate of bug 201743 ***