Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Ian Huff - Using VSTS Performance Tools to Speed Up Your App (Part 2)

Download

Right click “Save as…”

In the second half of my chat with Ian we talked about his brief (so far) history with Microsoft, dogfooding the performance tools, analysis best practices, common performance mistakes made by developers, and his favorite VS 2005 feature. 

All of this is packed up into a neat 7+ minute package for you.

What are the most common performance reducing problems you typically see in code?

josh

http://channel9.msdn.com/devdiv

Oh, if you missed it, check out the demo of our perf tools in part 1.

Tags:

Follow the Discussion

  • Very cool.  Small size (< 10 min), interesting info.  BTW, I totally agree on this.  There is a huge amount of laziness that is often inherant with new OO languages (C#,Java,VB.NET) because people don't realize how often the object is created.

    This should definitely be backported as a plugin or whatever to VS .NET 2003.  If only I knew some of the APIs (inherant to the .NET framework or otherwise), that would be cool.

    Yes, in a business context, I'm seeing how the purist "let's do everything in C" and the noob "I can code C# in 2 days" both go out the window.   It's interesting you mention the marshalling...it is a performance hit that does take a key role in C# development in the business world. 

    I'm still in school (as SA to Microsoft here in Jersey) and working part-time for a financial company.  So, I kind of see Josh's perspective very clearly.  If only the curriculum was much more practical - writing secure, fast code in the best language for the task and have unit/integration testing on that code.  Professors get overly religious about their favorite language (even Scheme, related to Lisp, for one prof I had) and don't actually teach or help us with this critical stuff. 

    [rant] BTW, most of us actually aren't going to be doing UNIX TCP-IP sockets programming in the near future for the record.  We will more likely be running a VS .NET or Eclipse debugger though...[/rant]
  • MinhMinh WOOH!  WOOH!
    Is it bad to allocate a value-type variables inside a loop?
  • Well,
    You don't really "allocate" value types in the same sense that you allocate objects.  Value types are on the stack (Correction: unless they are boxed).

    In my experience there is very litte difference from declaring a value type before a loop and changing its value to declaring it right in the loop.

    Also, it depends on the optimizations the compiler performs.

    But an interesting experiment would be just to load up VS.NET and try it.

    DateTime Start = DateTime.Now;
    int blah = 5;
    for (int i = 0;i < 10000000;i++)
    {
       blah = i;
    }

    Console.WriteLine(DateTime.Now.Subtract(Start));
    Start = DateTime.Now;

    for (int j = 0;j < 10000000;j++)
    {
       int blah2 = j;
    }

    Console.WriteLine(DateTime.Now.Subtract(Start));

    BTW - the results of this are -

    00:00:00.0468750
    00:00:00.0156250

    which is very interesting because it shows the second version actually being faster than the first!

    I am by no means an expert (I have only a little assembly experience on hand).  So if anyone wants to prove me wrong please do so.  Oh, and this code is not perfect (I spent like 20 seconds writing it), so please don't be too hard on me Smiley

  • PerfectPhasePerfectPhase "This is not war, this is pest control!" - Dalek to Cyberman
    nightski wrote:


    BTW - the results of this are -

    00:00:00.0468750
    00:00:00.0156250

    which is very interesting because it shows the second version actually being faster than the first!




    I found the same thing but only in debug, when compiled in release it's the other way round, except if you actually do something with the value in the loop at which point it's the same for both in release mode.

    Stephen.

  • MinhMinh WOOH!  WOOH!
    nightski wrote:
    In my experience there is very litte difference from declaring a value type before a loop and changing its value to declaring it right in the loop.

    I mean something like this would be bad for a reference-type, but I wonder if it'd have a performance/memory issue w/ value-type:

    MyStruct m;
    for (int i = 0; i < 1000000; i++)
    {
        m = new MyStruct();
        m.ID = i;
        ProcessMyStruct(m);
    }

    Or maybe the compiler would optimize all this away.
  • Well,
    a Struct is still being allocated on the stack.  If you are declaring 1000000 items on the stack, it probably isn't a good idea.  This type of problem is better suited for a reference type.

    Especially if you are calling ProcessMyStruct(m) because then the entire struct will be copied since it is passed by value.

    However, the struct will work the same way the int did, as a struct is just a combination of other value types.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.