Community
Participate
Working Groups
Created attachment 286496 [details] TCP dump Hello, I've faced with performance issue while trying to debug remote server using Eclipse. When I run my debug configuration in Eclipse it takes about 4-5 minutes but in other IDE or even in JDB from console it takes less than 1 minute (20-30 sec). I've gathered TCP dump from start launching debug until finish. It can be found in attachment. Based on dump, it seems that Eclipse tries to get a lot of Thread and Monitor information because there are a lot of small JDWP commands while launching ( to get thread statuses, to get thread groups and etc). At the same time, all checkboxes in debug view are disabled - show monitors, show running threads, show system threads and so on. Could you please check why eclipse send a lot of unnecessary JDWP commands?
Created attachment 286497 [details] Debug view
Created attachment 286498 [details] Debug configuration view
(In reply to Roman Bezugomonnov from comment #0) > Created attachment 286496 [details] > TCP dump > I've gathered TCP dump from start launching debug until finish. > It can be found in attachment. Could you please export it to some csv/text format, I don't have wireshark installed and don't want to mess up with this tool on my workstation. > Based on dump, it seems that Eclipse tries to get a lot of Thread and > Monitor information because there are a lot of small JDWP commands while > launching ( to get thread statuses, to get thread groups and etc). > > At the same time, all checkboxes in debug view are disabled - show monitors, > show running threads, show system threads and so on. > > Could you please check why eclipse send a lot of unnecessary JDWP commands? Roman, just guessing: do you have any (many?) breakpoints created, so might be that affects startup time? Beside this, you might be affected by extra communication due too many threads on remote side / thread name change listener we have in the debugger. Try to start Eclipse with -Dorg.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable system property.