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.
Self explaining, I'll add exact measurements later. Note that this issue has direct negative impact on performance of workspace switching.
I really do not know: 1) where is the problem, what is slow? First deserialization of workspace? Deserialization of DebuggerWindow? First loading of many debugger classes? 2) how to fix it - UI part, should I open some empty TopComponent? Should I write something to status line? 3) how to fix it in code. Should it be fixed in my code or in window system? Is is possible to fix it?
1) Very first open of debugger window during IDE session is slow. Just start clean build and try to open debugger window (on editing workspace). It takes significant amount of time. I promised measurements so I'll try to come with something. 2) I'm ccing Dusan Pavlica to help you with this. My view is that first try should be to sppeedup the code and then provide reasonable feedback if action is still not lightning fast. 3) Definitely in your code, in debugger. Winsys can do nothing with individual slowness of top components. However effort is needed on both sides, winsys guys will attack winsys workspace switching code during work on issue 27789.
add 3) I can not agree with this. I do not see any relevant data. I think that there is no real investigation on this task, so I can not plan resources on it. I will investigate this problem.
Haha, let's play the game :-) Here are numbers so that you can plan resources better :-)) first open of empty debugger window during ide session (View/Debugger window): 2453 ms, 2203 ms, 1859 ms second, third ... open: as separate window ~600ms, as inner pane ~150ms. Result: only very first open is problem, should take less then 1000ms ideally. Other then first opens are ok, although I don't know why is there so much difference between debugger window open as separate window and as inner pane. Do you need anything more?
HaHa still not relevant information. Still do not know: 1) what is slow 2) what to change in ui 3) what to change in code ;)) I understand that first open of Debugger Workspace is slow. And I know it may be two years. But there isno new relevant information in this bugreport. What is slow - deserialization of workspace, or mode? Deserialization of data serialized by debuggerWindow? Initialization of debugger window? Or am I loading too many classes during deserialization of debugger win.? Is it possible to fix it without breaking of backward data compatibility? Should there be some general patch is window system for such problems? .....
I think that I can not improve tis problem much. It looks like the most problems are in window system implementation. I can improve it about 30% only, and UI will be strange. We should try to do some more improvements in ws impl. For example: - do not deserialize hidden views - deserialize / create all views later - give some UI feedback to user when the window system is deserialized - remove all workspaces and rewrite / simplify current window system :))
I don't agree with reassigning to winsys because of following reasons: - winsys have special issue for workspace switching it's issue 30083 - Debugger window is slow as well when opened on editing workspace for the very first time, see my numbers above If you think you can't improve first open time of debugger window, or it's not desirable, please mark this one as WONTFIX and explain. Thanks. I'm reassigning back to debugger.
fixed in the main trunk - notification about initialization of workspace has been added to workspace - notification about initialization of Debugger Window has been added to status bar
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.