This post originated from an RSS feed registered with .NET Buzz by Steve Hebert. Original Post: Raw memory allocation speed - c++ vs c# Feed Title: Steve Hebert's Development Blog Feed URL: /error.htm?aspxerrorpath=/blogs/steve.hebert/rss.aspx Feed Description: .Steve's .Blog - Including .Net, SQL Server, .Math and everything in between Latest .NET Buzz Posts Latest .NET Buzz Posts by Steve Hebert Latest Posts From Steve Hebert's Development Blog

I've had several conversations on OO languages in the past couple of months.  Going back to the migration from C to C++, developers became dependent on the 'new' operator and many times did so without understanding the consequences. In C++, 'new' = malloc() + non-inline function call (constructor). 

So I started wondering - what are the performance differences between the C# and C++ new operators.  To test this, I intentially created a small class that gets allocated over and over.  To better compare the two languages since C# uses garbage collection, I intentially avoided the destructor call in C++.  Since I cannot avoid the garbage collector, I decided that best case C# won't have time to call the gc and worst case C# will be penalized for it.

That said, I created the following code in C++. Keep in mind this is for the explicit purpose of isolating the function of allocating an object and calling a constructor.

C++ code

class OneInt

{

public:

   int i;

public:

   OneInt()

   {

      i=1;

   }

};

int main(int argc, _TCHAR* argv[])

{

   OneInt* oneInt = NULL;

   for( int i = 0;  i < 20000000; i++ )

      oneInt = new OneInt();   // intentional memory leak to avoid destructor call

   return 0;

}

C#  code

class OneInt

{

   public int i;

   public OneInt()

   {

      i=1;

   }

}

class Main

{

   static void Main(string[] args)

   {

      OneInt oneInt = null;

      for( int i = 0;  i < 20000000; i++ )

         oneInt = new OneInt();

      }

   }

}

The results you ask?  On a Pentium 4 3.2 ghz box...

C++ averaged slightly more than 5 seconds to run.
C# averaged .15 seconds to run.

The +/- on both the C#/C++ code was less than .01 seconds, so I would consider that time to be TickCount resolution noise.

Having this type of code in a production environment is unrealistic - or at the very least, diplomas should be revoked.   I'm not sure how much you can mark up to the organization of the constructor call IL, but I suspect the allocation of system memory in chunks larger than the requested object is playing into this.  That task of preallocating memory and handling your own allocation pattern in C or C++ is very non-trivial work when the need arises.