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 issue was reported manually by gorrus. It already has 1 duplicates Build: NetBeans IDE 7.3 Beta (Build 201210011125) VM: Java HotSpot(TM) 64-Bit Server VM, 23.3-b01, Java(TM) SE Runtime Environment, 1.7.0_07-b10 OS: Linux User Comments: pzgyuanf: debug a program which does index a 4.0+M html file Maximum slowness yet reported was 3359 ms, average is 3359
Created attachment 126443 [details] nps snapshot
looks like terminal issue
*** Bug 220731 has been marked as a duplicate of this bug. ***
*** Bug 220729 has been marked as a duplicate of this bug. ***
pzgyuanf, was debugging console (Window->Debugging->Debugger Console) open during your debug session? When does these slowness problem occurred? Was is right after you tried to add a new breakpoint? Or during a step? Was there any intensive output to the terminal? Thanks, =Andrew
meta-comment. I loaded the nps file into NB and everything showed up as %100.
>was debugging console (Window->Debugging->Debugger Console) open during your debug session? It was the same case even if the debugging console were not opened. (Actually, I only opened it latest for tracking the gdb log file name, before, I did not realize NetBeans also has this console. :)) >When does these slowness problem occurred? Was is right after you tried to add a new breakpoint? Or during a step? In my program, there's a HTML token parser, not dom based, something like XML SAX event/handler base. I put a breakpoint on the entrance of the handler, so every time, if there's html tag, it would go through the breakpoint. However, after the debugger started and stepped, the execution did not reach the breakpoint, Netbeans ran slowly already, so I try to remove the breakpoint by toggle it at the left margin. But you know, I could not do that because the UI was frozen. I had to kill Netbeans process, yes, many times. Have one chance, because I need to according to the instructions supplied by Nebeans DEV to repo this issue, so I let it run and replying to the issue. Finally, I saw NetBeans got active and responded all my actions which I did while frozen - toggle the breakpoint/set the breakpoint on other line(s) and many other abnormal actions. :) I trust all these were recorded in the gdb debug log. >Was there any intensive output to the terminal? Because the slowness, I had to switch to external output window, Internal and Standard output windows were not working -- I means frozen. No, I actually turn off the DEBUG MACRO because of slowness, so there's almost no output text from the program. Hope it helps. Pprun
As the comment 9 in bug #219566, because the gdb prints the value of the tag, which is larger, so the gdb log file gets larger. Please refer that log file for detail.
Some questions: - what locale are you in? (unix locale cmd should provide a good answer) - Please go to Tools->Options->Misc->Terminal. - What is the value of Font? - What is the value of HistorySize? - what is the vale of WrapLines? - If WrapLines is false try with it set to true and see if that helps. - If Font isn't Monospaced, try Monospaced and see if that hlps. From the profile what I see is a lot of time gets consumed in ... one way to put is is figuring whether the horizontal scrollbar needs to grow. That's why I'm asking about WrapLines. Another factor that adds to the cost is if your locale uses some fonts that require double spacing. It's usually oriental locales that may have multi-cell characters. I think I have enough data to try some experiments too ...
ivan, see reply in lined below. > Some questions: > - what locale are you in? (unix locale cmd should provide a good answer) pprun@pprun-debian:~$ locale LANG=en_US.utf8 LANGUAGE= LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= > - Please go to Tools->Options->Misc->Terminal. > - What is the value of Font? > - What is the value of HistorySize? > - what is the vale of WrapLines? see the screenshots please. > - If WrapLines is false try with it set to true and see if that helps. I prefer wrap-line, so it should be true > - If Font isn't Monospaced, try Monospaced and see if that hlps. It should be Monospace because other mono font are too small IMO., and I did always prefer larger font size, say > 15. But it seems currently the default size is 16? (I found this default in a daily build because I have uninstalled beta) > From the profile what I see is a lot of time gets consumed > in ... one way to put is is figuring whether the horizontal scrollbar > needs to grow. That's why I'm asking about WrapLines. I don't like horizontal scrollbar so it should be wrapped > Another factor that adds to the cost is if your locale uses some > fonts that require double spacing. It's usually oriental locales > that may have multi-cell characters. The Debian installer did install Chinese package, but you know I need the same UI as other developers when discuss issue, so most of time I set the language to English in Gnome Shell. > I think I have enough data to try some experiments too ... BTW., the daily build (Product Version: NetBeans IDE Dev (Build 201210260001)) always shows up the slow notice while startup, even currently it only contains a minimal java project opened. (with cnd, without java ee and other heavy weight components then)
Created attachment 126656 [details] terminal setting
Created attachment 126657 [details] output windows setting
Another questions may not related to NetBeans only (may JDK): In order to get the same size, why the system font size is monospace 12, but Netbeans needs 16?
> No, I actually turn off the DEBUG MACRO because of slowness, so there's almost > no output text from the program. But the snapshot is from _before_ you turned off "the DEBUG MACRO" right? The snapshot shows that NB is being flooded with a lot of plain simple output. Funny fonts and horizontal scrolling would slow things down but we've ruled those out. If I run a toy artificial program that floods NB with output, say, infinite number of 5000 character wide letters, I don't get any freezes. Things are reasonably responsive. I can ^C in the output window and get reasonably quick termination. I tried the torture test program under Output->Terminal, using Run from a project and Debug. Responsive in all cases. I tried a know slowness scenario where an application puts things out one character at a time. NB was responsive (and in any case in the one char at a time scenario the profile is usually dominated by paints). One things which could explain the freeze would be if somehow the output from the application comes to NB in one humonguous chunk. (NB guys remember how there were problems with the build output not showing until the build was done? Something similar to that). The thing is output usually comes through pipes and pipes usually aren't humonguous. What platform is all of this happening on? How many cpus'? Can you run 'top' and see if any other processes are hogging the cpu?
Please provide some more information, otherwise it is impossible to investigate this. Also please try the latest dev build from http://bits.netbeans.org/download/trunk/nightly/latest/ with the latest java 7.