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.
[ BUILD # : 200809271401 ] [ JDK VERSION : other ] When we debug a web project and select client-side JavaScript debug on Firefox, if we click on 3-4 URLs quickly in the HTTP Client Monitor list, Netbeans hangs. Steps to reproduce: 1.) Debug the sample TravelCenter/VehicleIncidentReport project 2.) When the browser opens, we can see URLs listed 3.) In the HTTP Response select Body tab 4.) Double-click on 3-4 URLs quickly and Netbeans will hang for ~30-40sec Attached the Threaddump for investigating the hang.
Created attachment 71066 [details] The threaddump on the hang
I did reproduce this yesterday as well. Note this project is a sample Visual Web app, requiring JavaDB, GF v2.
Looks like this is a UI problem. By the time the monitor populates, the browser extension has already sent the relevant info to the IDE.
I tried to reproduce it. Some observations: 1) The Netbeans does gray out for 20-30 secs but it always comes back..I am not able to get a proper hang 2) I tried to reproduce it with other projects, Attach debugger to URLs and do not see this issue.. Krys, Can you take a look and confirm if this happens with sample project only or with any webapp? thx
I looked at this a bit and it seems that the Sun copyright in the large comment block at the header of some of the files causes the slowdown. The performance degradation may also happen in other specific cases as well.
Attaching thread dump data from an empty deployed visual web project. Could not reproduce for simple web, groovy or php projects, or using attach debugger to php web site or cnn.com with dozens of GET calls. IDE will appear to recover but the UI is unresponsive, cannot finish session.
Created attachment 71343 [details] initial two thread dumps
Created attachment 71344 [details] additional two dumps
Created attachment 71345 [details] another pair of thread dumps
Created attachment 71398 [details] Profiler call tree
we use the JEditorPane to show the response body and looks like editor is having performance issue while rendering javascript/css response body. I profiled the issue, please see attached call stack and hot spots - and looks like the editor.Analyzer is where the code is spending max time. This is consistent with the thread dumps attached. 2) I also feel its not a p2 since its a corner case - happening with only this project, with the body tab open (this tab is not the default open tab in http monitor) and the user has to quickly select rows.
Created attachment 71399 [details] Profiler hot spots
Ok, I'm making this P3 as suggested by sonali. This is likely to take some time to investigate and fix. The threaddumps show a lot of painting done in the editor. One approach would be to try to further improve the painting algorithm and I am not saying we should not do that. But on the other hand the editor seems to be able to respond reasonably well when typing even in a large file, so maybe we should try to investigate why there is so much painting done in your scenario. Or perhaps why painting in your scenario is slower than normally, if it is. I'm sorry I'm just thinking out loud.
Created attachment 71497 [details] Test project zip
I've attached a project that demonstrates the issue. When you use the client monitor (use client-side debugging on Firefox), selecting js-script-min.js is slow when the body tab is open. However, selecting js-script.js (which is the same except the text is formatted) does not have the performance issue.
Our QE, Krystyna Polomski, doesnt agree with my evaluation of it being a p3 as she finds the "client monitor unusable with visual web project". As per our discussion( will attach the email thread), am upgrading the bug to p2. There is a workaround to the issue - turn off the syntax highlighting for the body tab. We will lose syntax highlighting for xml, js and html but the performance benefits of the workaround is significant and we have decided to go with the workaround at this point of time. I will file a separate bug in the editor and link it with this issue. Krys, please update the bug with your evaluation also.
Performance should be significantly improved (3-4x faster) when rendering single-line files after turning off the syntax highlighting. At least on the machine I tested on, I was not able to get into a "hang" state (i.e. IDE stops responding for a long time due to switching client monitor entries rapidly). Changeset: e5c10521d432
Integrated into 'main-golden', will be available in build *200810111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e5c10521d432 User: Quy Nguyen <quynguyen@netbeans.org> Log: #148996 - Disable syntax highlighting in http client monitor response body tab to improve performance
Thanks for the fix as this problem affected all projects that would display single line javascript (minified) such as do many high performance websites. Fix verified in NetBeans IDE 6.5 RC1 (Build 200810151402) Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b13 System: Windows XP version 5.1 running on x86 Also, fix was verified by submitter.