Slow single stepping in VS2013 and Emulator

Archive
#1

I am attempting to debug my NETMF 4.3 (Raptor) project using the Microsoft Emulator under VS 2013 but I’m having serious debugger performance issues. Single stepping between lines takes 0.5 - 1.5 seconds. Hovering over a variable to get the value, or expanding the variable to see class state etc takes 2.5-4 seconds.

Is this expected? I can’t recall it being this slow under VS 2010. Is there anything I can do to speed up the emulated debug experience?

#2

Michael, I am seeing the same behavior. Hope we can find a solution to the problem.

Terrence

#3

The problem here is the extreme poor performance of the Emulator.
I don’t think there is a fix for that. it’s normal.

#4

I’ve taken a look at the debugger performance with a profiler and it seems to spend a lot of time on synchronization - mainly around waiting for a lock inside Microsoft.SPOT.Debugger.Engine.SyncMessage(UInt32, UInt32, Object, Int32, Int32) which is called by just about every single interesting thing the debugger does.

I’ve pulled down the debugger source to try and understand the debugger some more.

#5

I added some tracing to SyncMessage. If you hover over just one variable the SyncMessage method is invoked multiple times by multiple threads (the number indicates the ManagedThreadId). Each thread needs to take the lock which could be a bottleneck.

Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 50
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 48
Waiting on m_ReqSyncLock 48
Waiting on m_ReqSyncLock 50
Waiting on m_ReqSyncLock 50
Waiting on m_ReqSyncLock 50
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66
Waiting on m_ReqSyncLock 66

I’ll do some more digging.

#6

After much debugging of the debugger the biggest performance improvement was the removal of a Thread.Sleep between peeks of the debugger pipe.

99% of the time there is no data to receive from the debugger, so the dedicated thread for receiving data would block for 100 ms. This caused operations (step, get value) to queue up slowing everything down.

I’ve fixed this by making the reading from the pipe asynchronous so it doesn’t block. This has made the emulated debugging speed almost on par with the native .NET desktop C# debugger.

I haven’t tried this change against an actual board yet.

If you want the fix you can grab it from a change set here or ping me for a VSIX installer.

10 Likes
#7

@ Michael-b - You should defenetally post this on NETMF.Codeplex.com as well

1 Like
#8

@ Michael-b - Well done.

#9

Michael, great work.

I wonder if you would send me a vsix installer?

myname at mactexas . com

Thanks,
Terrence

#10

Yes I agree

#11

I’ve raised a work item on the NET MF project for this issue.

https://netmf.codeplex.com/workitem/2366

I’ll attempt to submit a patch and get the changes included in the standard NET MF release.

1 Like