Visual Studio 2010 Prof Slowdown on Win8 64bit

Hiyah All,

Just wondered if anyone else had experienced a drastic slowdown in responsiveness of Visual Studio 2010 with the latest version of Nsight Tegra? I think this may be an issue with the adb task not responding correctly, because if I manually kill adb.exe from the Task Manager then VS2010 will start to respond again.

After a little more investigation, VS2010 seems to get slower and slower every time I run the apk without debugging (Ctrl + F5), until eventually a single core of my machine is maxed out and VS becomes unresponsive.

Cheers

Nigel

hi NworbLegin,
I sorry that you meet this. this should not be thus. but I tried to reproduce on my box. I can’t reproduce your case. could you give more details about your case or simple sample to reproduce ?

I’ve un-installed the Tegra tools and re-installed but this problem is still here. I don’t think there is a simple sample I can put together to help you reproduce this, as it seems to be a problem in general with Visual Studio and the Tegra tools. At the moment I am forced to kill Visual Studio after 4-5 debugging sessions because it has become unresponsive.

I’m running VS2010 SP1 with Windows 8 64bit on an Quad Core i7 (pretending it has 8 cores). It’s only one of the 7 visible cores that are showing as maxed out in the resource manager.

Maybe this is a windows 8 problem?

Cheers

Nigel

A further update to this. Even if I don’t start any debugging sessions VS seems to become unresponsive after a period of time. Could this be a bug with the android debug logging? This problem happens if the logging window is active or not. Disconnecting the device sometimes brings VS back to life, but more often I have to kill the multiple adb instances and restart VS.

it was weird, I tried with HelloJni Demo. it run smoothly.

  1. disable/enable the logcat.
    10 times, the CPU is 3% average.
  2. run without debug. the CPU also 3%.

Maybe I should try re-installing VS2010 :-(

I have the exact same problem.
Restarting VS seem to help.

Hello guys,

Does the problem reproduces when the logcat window is closed?

Yes.

The problem occur when the device is disconnected and reconnected again.
Visual Studio stop responding on reconnecting the device.

The only way to make VS responsive again is to disconnect the device, but VS will stop responding again if the device is reconnected…

VS has to be restarted while the device is connected.

I took a look at “Process Monitor” while VS is not responding:

In case the image is offline: devenv.exe is in some sort of a loop of creating threads and killing them.

2435854	01:42:44.7138618	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 13640
2435855	01:42:44.8138286	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 13640, User Time: 0.0000000, Kernel Time: 0.0000000
2435856	01:42:44.9051924	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 10260
2435857	01:42:45.0058471	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 10260, User Time: 0.0000000, Kernel Time: 0.0000000
2435858	01:42:45.0864114	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 10112
2435859	01:42:45.1870033	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 10112, User Time: 0.0000000, Kernel Time: 0.0000000
2435860	01:42:45.4060391	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 10860
2435861	01:42:45.5069518	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 10860, User Time: 0.0156001, Kernel Time: 0.0000000
2435862	01:42:45.5917482	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 3632
2435863	01:42:45.6919427	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 3632, User Time: 0.0000000, Kernel Time: 0.0000000
2435864	01:42:45.7802930	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 7712
2435865	01:42:45.8808965	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 7712, User Time: 0.0156001, Kernel Time: 0.0000000
2435866	01:42:46.2009756	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 16660
2435867	01:42:46.3009571	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 16660, User Time: 0.0000000, Kernel Time: 0.0000000
2435868	01:42:46.3881767	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 980
2435869	01:42:46.4889963	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 980, User Time: 0.0000000, Kernel Time: 0.0000000
2435870	01:42:46.5759287	devenv.exe	11432	Thread Create		SUCCESS	Thread ID: 9908
2435871	01:42:46.6764915	devenv.exe	11432	Thread Exit		SUCCESS	Thread ID: 9908, User Time: 0.0000000, Kernel Time: 0.0000000
.
.
.

Hello EliH_x,

Thank you for the detailed explanation. We’ll certainly look into it!

Every computer at our studio suffers from this same problem. We are running Windows 7 64-bit.

Whenever we press ctrl-F5, Visual Studio becomes completely unresponsive, uses 100% of one core’s cpu time (in our case that’s 25% since we have quad cores), and we either have to kill the Visual Studio process or wait for it to recover. It often will not recover at all until we exit our application on the device, or disconnect the device from our PC. After that time, it can take 1-2 minutes for Visual Studio to start responding again, although I have at times left it for 15+ minutes and came back to it still stalled.

While it’s using the CPU this way, according to task manager, it’s allocating ~250K of RAM per second and the number of threads is flipping up and down seemingly at random.

It also appears to be worse when we have a large number of Android log statements, such as an error which occurs every frame.

we believe this has been addressed in the upcoming release - stay tuned

this should be fixed in the latest release - please try it out and let us know if you still have a problem - cheers!

After updating to the latest release I still have a very long delay in VS after I stop debugging my Android App. It seems that the application does not quit and visual studio takes at least a minute to become responsive again. Is there somewhere I can change a timeout value to speed this up?

Cheers

Nigel

Hello Nigel,

This is a known issue that will be fixed in the future.

For now you could try setting Tools -> Options -> Android -> Debug -> Timeout to a lower value (1 second, for example). The delay scales with the number of breakpoints, so keeping it low will help the matter as well.