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.
NetBeans 7.1 is terribly slow: It's scanning takes ages and blocks almost any UI action. Also, almost any UI action triggers project scanning. This situation doesn't get better after hours of using, still the same situation. I have also tried what always worked - remove ~/.netbeans/var/ directory, start from fresh and wait for a day until it scans everything again, but didn't help. This makes 7.1 unusable (really, no exaggeration). Hence P1. 7.0.1 works fine (and I reverted to it). I don't know what data can I provide. So here is at least my scenario: 1) git clone git://github.com/jbossas/jboss-as.git 2) cd jboss-as 3) git checkout origin/master 4) mvn clean install 5) Open the project in NetBeans 6) Open few modules - arquillian, web, webservices, testsuite/integration/basic 7) Download all their dep's sources and javadoc 8) Watch NetBeans Scanning all the time, causing heavy lags in UI and even blocking some operations, including but not limited to, code completion. Sun JDK 1.6.26. Linux 32-bit.
Do all those "LowPerformance took 123456 ms" say the same? http://netbeans.org/bugzilla/buglist.cgi?cmdtype=runnamed;namedcmd=perf-7.1;list_id=16836
The only difference in netbeans.conf I found is -J-XX:MaxPermSize=384m in 7.0.1. Trying that with 7.1.
Wow. Can't believe. I added -J-server -J-XX:MaxPermSize=384m netbeans.conf, resulting to netbeans_default_options="-J-server -J-Xss2m -J-Xms128m -J-Xmx1600m -J-XX:PermSize=32m -J-XX:MaxPermSize=384m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.zip.disableMemoryMapping=true" After that, NetBeans auto-upgraded 55 modules (it's possible that was blocked by bug 209192 which now doesn't appear). And now, it's the fastest IDE I've ever seen! Scanning JBoss AS 7 takes few seconds, code completion appears without any delay. Marvelous. I need to evaluate for a while to verify.
Inspired by http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html, I've played a bit more, ending up with: netbeans_default_options=" -J-server -J-Xss2m -J-Xms128m -J-Xmx1600m -J-XX:PermSize=32m -J-XX:MaxPermSize=384m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.zip.disableMemoryMapping=true -J-XX:+UseCompressedStrings -J-XX:+OptimizeStringConcat -J-XX:+UseFastAccessorMethods -J-XX:+AggressiveOpts -J-XX:CompileThreshold=1000 -J-XX:-RelaxAccessControlCheck -J-XX:+UseStringCache -J-XX:ReservedCodeCacheSize=128m" The most significant change is probably -XX:CompileThreshold=1000, which causes the bootstrap sequence to look like stuck for a while, but after that, it gets to the fast-pace mode. No significant improvement against the combination from previous comment.
I still wonder why the MaxPermGen was missing - I don't remember removing it, and I would never do that anyway. Was that intentional, trying to reduce memory usage? Or relying on some new JDK default? It also seems that "PermGen full" is somehow swallowed. If so, wouldn't be better to increase that setting in netbeans.conf on such error?
Reassigning to Tomas for evaluation.
Hello, if the problem is that MaxPermSize was not set properly by default we need to assign to a different category. Is there anything else in this report that might help fixing the observed problems? Thanks, David
The issue has 2 parts: First regarding the scan to be in background: Fixed in dev (7.2), The scan runs on background 41985eb45913. Also regarding the point 7 >7) Download all their dep's sources and javadoc The problem was that maven deps dowload triggered several random scans, also resolved in dev fc07aef4b575. See http://netbeans.org/bugzilla/show_bug.cgi?id=208213 Second missing MaxPermSize is caused by launcher. I've created a new issue for launcher #209457.