Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Performance issue with the thread tree in Debug View
Which version of CDT are you using?
 
This performance issue might be a consequence of
Bug 291628 - [debug view][vm] Redundant updates on FullStackRefreshEvent
 
Toni
 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ??
Sent: Friday, April 23, 2010 5:32 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Performance issue with the thread tree in Debug View

Hi guys:
    We find there is performance issue with the Debug View Part
 
    Our Situation:  we have almost 1000 threads in the same process under debugging, thus there are 1000 threads in the thread tree of Debug View.
   
    The issue: DSF refreshes every thread on a suspend event, which results in send 2 commands to GDB: "-thread-select thread_No" and "-stack-info-depth". We've got 2* 1000 = 2000 commands sent in total! It's really a performance killer.
 
     Our observation: The refresh request comes from the AbstractLaunchVMProvider in org.eclipse.cdt.dsf.ui  line 149 - line 200
 
       

@Override

protected void handleEvent(IVMModelProxy proxyStrategy, final Object event, RequestMonitor rm) {

               // sends FullStackRefreshEvent to each suspended thread, which cause the refresh

}

        Our action: We haven't found a good solution for it yet.

                 1) We tried to disable the refresh in AbstractLaunchVMProvider, then:

                            a. Before resume the debugger. thread 200 - thread 210 (10 threads) can be seen on Debug View

                            b. Resume the debugger

                            c. Thread 200 - thread 210 are update to running state

                            d. Debugger hits the breakpoint on thread 500

                            e. TreeModelViewer sends the update  to refresh thread 500 - thread 510

                            f. Scroll the scroll bar on Debug View, The up-coming threads will get refreshed

                            g. Scroll and scroll until we go back to thread 200 - thread 210

                            h. thread 200 - thread 210 remains the running state, they missed the suspend update

 

        So do you guys have plan to deal this performance issue?

        Thanks!

 

Regards

邢云

 

                                                   

 

   

 
             


Back to the top