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 185294, 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 201206100001) VM: Java HotSpot(TM) 64-Bit Server VM, 23.0-b21, Java(TM) SE Runtime Environment, 1.7.0_04-b22 OS: Windows NT (unknown) Maximum slowness yet reported was 5751 ms, average is 5751
Created attachment 120620 [details] nps snapshot
Created attachment 120917 [details] nps snapshot Opening a maven project for the first time.
Both snapshots seem to be related to EditorKit. Warming up when BaseKit.call() is called could help, imho.
592129: OpenAction (called in AWT) is synchronous which leads to openDocument() which requires an editor kit which needs to be searched in MimeLookup which initialization causes a slowness. 591512: Not sure whether warming up BaseKit would help but I may try.
102 duplicates - most of them new -> setting priority to P2
This issue is hodgepodge of different slownesses from many components (editor, options, bugtracking...) which have one thing in common - in all of them most of the time spent in awt is spent class loading i.e. in methods: java.util.zip.ZipFile.read[native]() java.util.zip.ZipFile.open[native]() java.util.zip.ZipFile.getEntry[native]() There should be some general solution to this problem. We should either in some way pre-load the classes or just show empty UI with some "loading" indication until the ui component is ready.
just to throw my opinion, i'm not convinced we need to solve this sort of issue. (classloading stopped at IO operations) Native applications most likely suffer from IO related slownesses as well and so far I haven't seen anywhere a similar solution to the problem. Actually I believe the problem becomes largely "unsolved" as there is not really a solution. I suspect that once we solve the issue of slow IO we will gradually see the problem leaking elsewhere. Obviously I have no solid arguments proving my point, I'm just not a fan of generic solutions..
Native Applications consist of DLLs (not neccesarily by that extension) which either get pre-loaded during startup of the application, or get loaded when some of their functions are called for the first time in the application process lifecycle. Native applications certainly experience slowdown when DLLs need to be loaded in, but at least the whole DLL is loaded & linked at once, rather than once per class file. Also, depending on the OS & Compiler, applications get a chance to optimize the process by pre-loading certain DLLs and by controlling which code resides in which DLL (irrespective of any defaults derived from module / package name). JAR files could in theory be optimized to contain only code which you want to be loaded together, splitting classes from same package over various JAR files, which is a lot of work in your build scripts, but since to my knowledge Java doesn't pre-load JAR files there's not much benefit. So I do believe that for Java, class loading is an overhead which is occurring more frequently than the DLL loading in a native application. I don't know how other large Java applications handle this issue, because for sure NetBeans isn't the only Java application struck by this problem. But other than that, I'd say that this is a problem between the JVM and the OS. Personally on my system, full-disk-encryption at the very lowest level slows down overall performance. This might also introduce extra bottlenecks which wouldn't normally be there in a more standard Windows PC. I don't know if this is somehow the same for others who are reporting issues like this.