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.
Created attachment 130189 [details] Profile of IDE during slowness I have two projects open, a web service project and a web application. I have an instance of Glassfish 3.1.2 in the services tab. I have disabled "deploy on save" for both projects since this can slow things down significantly. I randomly encounter unexplained slow downs (unrelated to scanning of projects); In this case, I was editing Java code. Hopefully the attached profile will provide some insight into what was happening.
Submitting a profile from another occurrence, this time the Xmx option has been set to 1024m instead of 512m as was previously the case.
Created attachment 130201 [details] Profile of IDE during slowness
I have taken a heap dump of netbeans shortly after the second profile was taken. The CPU was still at 100% during the heap dump so the problem was still persisting at that point. I can't upload the heap dump due to the size but if you would like me to make it available to you, please contact me and I will. Phil
*** Bug 224855 has been marked as a duplicate of this bug. ***
Created attachment 130245 [details] Profile of IDE during slowness
According to the fisrt snapshot, it looks like a lot of time is spent in org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints() method both in 'Editor Parsing Loop' and 'org.netbeans.api.progress.ProgressUtils' threads. Reassigning to java/hints for further evaluation.
The heap dump might be useful - could you please try to upload it here: http://deadlock.netbeans.org/hudson/job/upload/ Thanks.
I have uploaded this as build id 136. Note that I compressed the file with gzip before I uploaded it. I notice that Hudson zips the file on the server side so you may need to decompress the resulting file with gzip before you can use it.
Created attachment 130258 [details] Profile of IDE during slowness Hope I'm not overloading this with snapshots, just hoping that enough data will allow this to be narrowed down to a specific cause.
Thanks for the heap dump. It seems to me that the biggest problem is that there are almost 149166 instances of org.netbeans.modules.db.explorer.node.NodeRegistry, which the probably holds more objects, leading to a lot of memory retained through it. These appear to be held though a lookup listener. I will attach a possible patch. The hints maybe could be made faster (and produce less garbage) - filled #224954 for that.
Created attachment 130279 [details] A possible fix.
(In reply to comment #11) > Created attachment 130279 [details] > A possible fix. Thank you very much for the patch. Applied as http://hg.netbeans.org/core-main/rev/32bc4f6809be
Integrated into 'main-golden', will be available in build *201301180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/32bc4f6809be User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #224856: NodeRegistry uses weak lookup listeners