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

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]

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

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.

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.