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.
I've been using NB 5.0-beta for the past few days and have been frustrated by a number of apparent hangs while performing various operations in the IDE. Unfortunately it hasn't been obvious what exactly is causing the "hang". For example, I will click on a tab in the editor to switch to a different document, and then the whole IDE will lock up (completely unresponsive to mouse clicks or keyboard input). I will let the app continue to run, and then after 5-15 minutes, the IDE will be come responsive again and I can continue to edit files without difficulty. This happens at least once per hour, as far as I can tell. As I mentioned, it's not always clear what action causes the hang/slowdown; sometimes I will just click somewhere in the editor window while editing a Java file, and one of these hangs will occur. I'm running NB 5.0-beta on Mustang b56 on Windows XP SP1. For each of these unresponsive occasions, I've used the jstack tool to capture the Java stack traces for the NB process, which I will attempt to attach to this bug report.
Created attachment 26050 [details] jstack output (#1 of 6)
Created attachment 26051 [details] jstack output (#2 of 6)
Created attachment 26052 [details] jstack output (#3 of 6)
Created attachment 26053 [details] jstack output (#4 of 6)
Created attachment 26054 [details] jstack output (#5 of 6)
Created attachment 26055 [details] jstack output (#6 of 6)
Although the first reading of the report resembles general problems with full GC that have a common pattern - running code performs regex pattern matching in javadoc files called from org.netbeans.modules.javacore.parser.ClassFileInfoUtil.getNamesFromJavaDoc() Can you add more details about your configuration? What kind of project / does it have dependencies (on libs, w/ or w/o sources or javadoc)?
Please provide information what javadoc is used in your project and where it is located. Thanks.
I am trying now with a simple project with a dependency on JADE-6.1 that is defined as library (binary JAR + javadoc as a directory tree on my local disk). The times are too long IMO on my PentiumM/1.7GHz/1GB. PERF: createParamsInfo()#javadoc-names 'valueOf' took 13 ms. PERF: createParamsInfo()#javadoc-names 'setPivotComparator' took 6 ms. PERF: createParamsInfo()#javadoc-names 'solve' took 8 ms. PERF: createParamsInfo()#javadoc-names 'construct' took 10 ms. PERF: createParamsInfo()#javadoc-names 'exportOperable' took 12 ms. PERF: createParamsInfo()#javadoc-names 'toHeapOperable' took 10 ms. If I got it right we are reparsing the file for each params info including running Javadoc4BinaryQ and we do it even for private method that are not displayed in completion. So hopefuly there is a space for improvements.
My machine is a 2x 2.8 GHz P4 with 1GB RAM. My project is a small Swing app (3 or 4 Java source files) I wrote for playing around with the JOGL library. I created a library from jogl.jar and included the javadoc as a directory tree, both of which are on my local disk. You can find recent nightly builds of JOGL and its associated javadoc here: http://download.java.net/media/jogl/builds/daily/2005-10-11/jogl.jar http://download.java.net/media/jogl/builds/daily/2005-10-11/javadoc_public.zip If you want a good stress test for NB javadoc parsing and code completion, I think JOGL is it :) Specifically, the javax.media.opengl.GL interface has hundreds upon hundreds of methods and constants. I wouldn't be surprised if that is the reason for the slowdowns reported here. However, I seem to remember seeing similar "hangs" even before I added JOGL as a dependency for this project, although I can't be sure. Sorry for leaving this info out of my original bug description, I forgot that the JOGL dependency could be very relevant to this bug report. Let me know if you need more info. Thanks.
Removing INCOMPLETE, user provided requested info.
Reproducible with provided information - the library contains classes either compiled without -g (missing parameters names) or abstract classes/interfaces (they do not have parameters names in .class files.) As the javadoc is available, it computes names for completion from javadoc. GL.html javadoc file for GL.class is 3685392 bytes length. So searching in it cost really much time :-(. We will try to improve peformance of this computation, but I'm not sure we will be able to speed it up enough. Bear in mind that it is slow only in first completion usage on selected class. For the time being, you have two choices how to workaround it - Either umount javadoc from library (you will not get parameters names in completion then) or provide sources to libary (javadoc will not be used anymore and names will come from sources files.)
Fixed in trunk. Now the data are processed to map for the whole file and then read from this map. Processing of GL.html (with 1919 methods) takes ~2 seconds. Use -Dperf.refactoring for obtaining some performance data. /cvs/java/javacore/src/org/netbeans/modules/javacore/parser/ClassFileInfoUtil.java,v <-- ClassFileInfoUtil.java new revision: 1.33; previous revision: 1.32 done