Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: RE: [cdt-dev] Performance issue with the thread tree in Debug View
The bug is marked as fixed in 6.1 (which is now actually 7.0), i.e. in 6.0.2 the bug is still present.
 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ??
Sent: Friday, April 23, 2010 9:39 AM
To: CDT General developers list.
Subject: 答复:RE: [cdt-dev] Performance issue with the thread tree in Debug View

Hi
  Great! We've tried the patch and it works!
 
  I recall that once i had a glance at this Bug,  and then wondered why this guy claim it fixed but in fact not.
 
  Thanks a lot!
Regards

 

在2010-04-23 14:59:31，"Leherbauer, Anton (Toni)" <Anton.Leherbauer@xxxxxxxxxxxxx> 写道：
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

邢云

 

                                                   

 

   

 
             




有域名马上来，网易免费送你200户域名邮箱

Back to the top