The following settings should produce better-than-factory setting performance on most systems.
* -Xverify:none - this switch turns off Java bytecode verification, making classloading faster, and eliminating the need for classes to be loaded during startup solely for the purposes of verification. This switch improves startup time, and there is no reason not to use it.
* -Xms32m - this setting tells the Java virtual machine to set its initial heap size to 32 megabytes. By telling the JVM how much memory it should initially allocate for the heap, we save it growing the heap as NetBeans consumes more memory.
* -Xmx256m - this settings tells the Java virtual machine the maximum amount of memory it should use for the heap. Placing a hard upper limit on this number means that the Java process cannot consume more memory than physical RAM available. This limit can be raised on systems with more memory. Current default value is 128MB. Note: Do not set this value to near or greater than the amount of physical RAM in your system or it will cause severe swapping during runtime.
More exotic switches
Listed below are some additional JVM switches which have either anecdotally or measurably impacted NetBeans performance on some, not all, systems. Your mileage may vary, but they may be worth a try.
* -XX:+UseConcMarkSweepGC or -XX:+UseParNewGC - try these switches if you are having problems with intrusive garbage collection pauses. This switch causes the JVM to use different algorithms for major garbage collection events (also for minor collections, if run on a multiprocessor workstation), ones which do not "stop the world" for the entire garbage collection process.
* -XX:+UseAdaptiveSizePolicy - this switch may help improve garbage collector throughput and memory footprint. It is part of garbage collector ergonomics implemented in JDK5.0.
* -XX:+UseParallelGC - some tests have shown that, at least on systems fairly well equipped with memory, the durations of minor garbage collections is halved when using this collection algorithm, on uniprocessor systems. Note that this is paradoxical - this collector is designed to work best on multiprocessor systems with gigabyte heaps. No data is available on its effect on major garbage collections. Note: this collector is mutually exclusive with -J-XX:+UseConcMarkSweepGC. . The measurements supporting the use of this algorithm can be found on the performance website.
* -XX:+PrintGCDetails - this is similar switches (like -J-verbose:gc) do not improve performance but provide diagnostic data showing information about memory management that are useful source of input for performance tuning. Another way how to obtain these data is to use monitoring tools or (NetBeans) profiler.
* -XX:CompileThreshold=100 - this switch will make startup time slower, by HotSpot to compile many more methods down to native code sooner than it otherwise would. The reported result is snappier performance once the IDE is running, since more of the UI code will be compiled rather than interpreted. This value represents the number of times a method must be called before it will be compiled.
* -Djava.net.preferIPv4Stack=true - this switch will suppress use of IPv6 stack in networking code and it can avoid small delay during startup when inet address is being resolved. It will be usefull only on a system where IPv6 is installed but not actually configured. Note: there can be another problems related to IPv6 - see for example discussion on interaction between fwbuilder and Java apps