答复:RE: [cdt-dev] Performance issue with the thread tree in Debug View

[邢云 <mouzonherry@xxxxxxx>]

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户域名邮箱