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.
[ JDK VERSION : 1.5.0_02 ] There is two (related) parts of this bug: I'm on XP Pro SP2, on a 1.6GHz Centrino Laptop. When I'm debugging and the thread pane is visible on the front, it take as mush as 2 seconds to just draw the content of the thread pane at each breakpoint, or single step. That's incredibly slow, and during the redraw, there is a lot of repaint with text that disappear and then reappear again and all sort of weird visual feedback. That makes that pane almost unusable. Now, (2nd part of the bug): If the program under debug is running, (not stopped on a BP or anything) and the thread pane is visible, then the IDE takes 99% of CPU time of my laptop. That slows down everything on my laptop, turn on the fan (noisy) and kill my battery. To sum up: the thread pane is not implemented correctly, there are major inefficiencies and/or misdesign in that code. Please review it. Thanks, Cedric
Thanks for report but I am afraid it is too late to improve efficiency of this view for NB_4.1
Redrawing is fixed, as far as I know. 100% CPU remains.
No, redrawing isn't fixed (issue 55225 is stil open as it should be), only slightly improved.
Just to make sure there isn't a misunderstanding about this issue: This is, I believe, not a question about efficiency. The threads view keep consuming 100% no matter how long you wait. Also, if you try to collapse a thread group you don't want to watch, in the hope that less CPU would be consumed, it opens up again after about a second. Something is wrong with this view, and the fact that it is (for me at least) activated automatically whenever the debugger is started, makes it even worse. Is P4 really the right prio for this issue? I'd give it at least P2 if it were up to me.
I agreee about the last comment. I'm putting back to P2, because having NB consuming 100% of the CPU during debugging is not just a little P4 annoyance.
P2 => must be addressed in the next release. Scheduling for 4.2. Reproduced the strange behavior of never ending collapsing and expanding of some nodes. But the CPU consumed just about 0 - 30%, and occasional short peaks of ~90%
The BasicThreadsTreeModel dictates to redraw the threads view every 2 seconds regardless of the speed of actual redraw in the GUI. The management of tasks in this class is a mess...
The tasks management rewritten. No functional change, it's just more readable and properly synchronized: /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/models/BasicThreadsTreeModel.java,v <-- BasicThreadsTreeModel.java new revision: 1.7; previous revision: 1.6
Partially solved, though it's not perfect yet. But for most typical usages (debugging an app on the same host, and an averadge CPU) it should work fine. Also the nodes can be expanded/collapsed now. Due to the above reasons, downgrading to P3. It still remains to take the actual redraw time into account and not to update the model faster that it can be refreshed. /cvs/debuggercore/viewmodel/src/org/netbeans/modules/viewmodel/TreeModelNode.java,v <-- TreeModelNode.java new revision: 1.30; previous revision: 1.29 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/models/BasicThreadsTreeModel.java,v <-- BasicThreadsTreeModel.java new revision: 1.8; previous revision: 1.7 /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/models/ThreadsTreeExpansionModel.java,v <-- ThreadsTreeExpansionModel.java new revision: 1.3; previous revision: 1.2
We'll be caching the retrieved threads to assure that the change events are not fired faster than repainting the window. It should also suppress the "Please wait" nodes that currently appears during the repainting and cause unexpected collapsing and expanding of the tree.
Even when issue #67143 is implemented and threads are cached, the performance is not superior (although it's much better). The additional CPU is lost in checking for monitors (even when they are not diplayed) and assignment of ThreadWithBordel marking class. This is in MonitorModel filter model. It would be good if we could get rid of ThreadWithBordel and load monitors on demand only.
It's much better after the fix of issue #67143. Specifically /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/models/ThreadsTreeModel.java,v <-- ThreadsTreeModel.java new revision: 1.5; previous revision: 1.4 The threads view eats 10% - 15% CPU when < 100 threads are running in the debugged application. If we remove the ThreadWithBordel, we would not be able to remove the expansion icons from threads that do not have monitors. Therefore this fix seems to be sufficient IMHO.
Thanks for fixing this. I've a little question though... What does "Bordel" means in "ThreadWithBordel"? "Bordel" means "Brothel" in French, so it's a rather funny name..
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.