Community
Participate
Working Groups
In the latest WSAD drivers that are based on ECLIPSE 2.02 it takes 10 to 15 minutes for debugger to come up when using "Run-time workbench" launch config. This was roughly 3 to 4 minutes 2 weeks ago.
Darin, this is 2.0.2. We didn't make any changes in launching code in 2.0.* stream. Ideas?
Are any breakpoints set? We know that method exit breakpoints are slow (a VM limitation).
It seems that initializing a significant number of plugins takes long time. WSAD has over 900 plugins.
I am curious if you are using any other PDE function prior to launching in debug mode. PDE must compute plugin paths and other information related to the target platform, so you normally pay a one-time price for discovering this information in the target plaform. For large products (with 900 plugins), this takes more than we would like to. However, as I said this is a once-per-session hit and should not happen every time you launch, and if you used function like plug-in import wizard, manifest editor, compute classpath etc., you already paid the price. After the process has been created, the rest of the startup time is due to the initialization of the second (target) instance.
We also noticed the problem and with the very recent integration builds. It only happens in debug mode and it is after the PDE launcher i.e. we launch the process fairly quickly, and return. The rest of the startup is in debug. Moving.
We will need the test case that causes the problem - i.e. is it WSAD or the SDK?
My feeling is that this has to do with a number of plugins. WSAD ships over 900 plugins. I will try to limit the number of plugins and give it a try once I manage to download the latest WSAD driver :)
We ran into the same problem with WSADIE and have found where the problem is and a simple work around. The problem is not with the number of plugins as previously mentioned in this bug report but with the number of Features. When starting the runtime-workbench in debug mode all of the time is spent reading/processing the feature information. We have monitored the files being accessed and paused the debugger, both pointed us at the features. With this as our assumption, we renamed the existing features directory and then created a new features directory. After looking at the install.ini to determine which feature was the only one required, we copied this feature into the new features directory. The line in the install.ini is "feature.default.id=com.ibm.wsappdevie.win32", so the only feature in the directory is now com.ibm.wsappdevie.win32_5.0.0. After making the above change, the debug mode startup time is 2-3 minutes which is acceptable based on the number of plugin currently in WSADIE (last time I checked it was 1130). I hope this helps.
It sounds like we can say that this is not the "debugger's fault" then? If so, where should this bug be placed? It sounds like a performance issue for someone.
Reassigning to the Core. Hopefully, they'll know where this belongs.
Christophe, will our M4 performance improvements affect this problem?
Action Taken: recent changes in M4 will help the issue 1) performance improvement when reconciling (bug 26947) 2) UI does not call UM anymore upon startup (bug 27358) Action Plan: close
