VS2010 vs VS2012 Debug Startup Times

Archive
1

In reference to a posting in another thread I did a brief comparison of debug times between Visual Studio 2010 and 2012 (Universal version) running on my Windows 8 Enterprise development system. Can someone try this and confirm my findings as I’m wondering if some special tools that I have installed with VS2012 are impacting my timings.

First the setup, the simplest app I could think of, a Hydra board flashing its debug LED every second. A new project was started for each version of VS to avoid any impact of conversion.


namespace DebugTiming
{
    public partial class Program
    {
        private GT.Timer _timer = new GT.Timer(1000);
        private bool _flash;

        // This method is run when the mainboard is powered up or reset.   
        void ProgramStarted()
        {
            /*******************************************************************************************
            Modules added in the Program.gadgeteer designer view are used by typing 
            their name followed by a period, e.g.  button.  or  camera.
            
            Many modules generate useful events. Type +=<tab><tab> to add a handler to an event, e.g.:
                button.ButtonPressed +=<tab><tab>
            
            If you want to do something periodically, use a GT.Timer and handle its Tick event, e.g.:
                GT.Timer timer = new GT.Timer(1000); // every second (1000ms)
                timer.Tick +=<tab><tab>
                timer.Start();
            *******************************************************************************************/


            // Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
            Debug.Print("Program Started"); <<<<<--- When the debug reached a breakpoint here the time was stopped

            _timer.Tick += new GT.Timer.TickEventHandler(_timer_Tick);
            _timer.Start();
        }

        void _timer_Tick(GT.Timer timer)
        {
            _flash = !_flash;
            Mainboard.SetDebugLED(_flash);
        }
    }
}

Times
Initial Compile and Debug
VS2010 - 16.92 sec
VS2012 - 35.35 sec

No code changes, just debug runs (2 runs)
VS2010 - 11.65 sec, 11.54 sec
VS2012 - 23.24 sec, 22.74 sec

Next I let ReSharper have its way with the code in removing unused usings and references and then did a build debug run
VS2010 - 15.61 sec
VS2012 - 29.70 sec

No code changes, just debug runs (2 runs)
VS2010 - 11.37sec, 11.17sec
VS2012 - 21.43sec, 22.21sec

So on my machine and with my Visual Studio setup it does appear that VS2010 is faster, but like I said can someone try this and let me know.

2

I believe that the startup time improvements are related to NETMF 4.3, not VS2012. I could be wrong on that, but it was my understanding.

I also believe that GHI has incorporated at least some of the relevant changes into the current 4.2 SDK. Again, that is my understanding.

As to why VS2012 is so much slower, there could be many reasons. All sorts of things can and did change, and none of them specifically related to NETMF.

Things also don’t look good for ReSharper.

3

Sorry I should have mentioned that both are using .NET Micro Framework 4.2

I didn’t expect ReSharper to drop the times by much as the compiler also removes these but code wise its always nice to get as much unused stuff as possible out of your code (ie ReSharper removed all the using except one from the usings section and removed all but 5 of the references without any ill effects (ie the app still runs)).

4

you probably need to run this test a number of times and take the average. i don’t believe resharper removing of references will affect run time performance, just compile time.

its interesting that vs2012 is twice as slow…maybe examing and comparing the build out put might offer some clues…i wonder it’s doing some additional liking or loading of libraries or themes to support backward visual compatibility.

5

You know this is built-in to VS2010 and VS2012, right?

Also, usings have no effect on startup time, indeed, they have no effect on the compiler output at all. They’re just a convenience for coding.