Thursday, 5 June 2008

Performance of C# vs C++

Many people see C# as a fine language for business applications, but feel it lacks the low-level capabilities of C++ for software which is close to the metal.

C# includes many features such as the unsafe keyword that allows you to achieve most of what you could do in C++, but even without the use of unsafe code performance-intensive programming is possible. I was recently involved in a large project where I had the opportunity to compete with a C++ team, by writing an equivalent program from scratch in C#. Without wishing to break my NDA, the application involved much bit-twiddling, video, networking and the like. Originally I kept in an existing C++ library, but ended up using C# exclusively.

The C# code was around 20% of the size of its C++ equivalent, measured using a sophisticated tool that ignored layout, comments etc. Performance ended up being about the same – there were initial performance problems with the C++ version which were fixed by some serious coding work.

Where I expected the C# version to fall down was with load times, due to the just-in-time compilation. In fact this was very noticeably faster in the C# version – I presume that the JIT overhead was compensated for by the smaller code size.

It would be nice to try something similar with Visual Basic one day!

Labels: , ,

Tuesday, 3 June 2008

Casting, 'is' and 'as' in C#

I was giving a course for a gaming company who were understandably interested in performance issues. One of the things discussed was the relative performance of traditional casting versus is and as, so I had a play.

The general idea is that you have a reference variable of a base class type, which may be referring to an object of a derived class. This derived class has additional members which you wish to use, so you need to have a reference of the derived class type. For example:
BaseClass b;
...
DerivedClass d = b;
d.AMethodOnlyDerivedClassHas();

And of course the second line above will be thrown out by the compiler as BaseClass is less than DerivedClass in hierarchy terms.

A C-style cast could be used, for example:

DerivedClass d = (DerivedClass)b;

If you definitely know that b refers to a DerivedClass object then this is the fastest technique, about 5% faster that using ‘as’. But if b does not refer to a DerivedClass object (or an object of a class derived from it) then an exception is thrown, which is extremely expensive.
When b may or may not refer to a DerivedClass object, ‘as’ is useful as it gives null when the object is not the expected class, for example:

DerivedClass d = b as DerivedClass;
if ( d != null )
{
d. AMethodOnlyDerivedClassHas();
...

This technique allows us to test and cast simultaneously. Although it is a bit slower if the object is the tested-for type, it is enormously faster (>200 times) than catching the exception that the C-style cast throws.

‘as’ is widely used because it allows us to combine the testing with the assignment to a reference of the correct type. ‘is’ can be used just to perform the test, for example:

if ( b is DerivedClass )
...
And in fact ‘is’ and ‘as’ both use the same CLR code, so cost the same. Don’t do this though:

if ( b is DerivedClass )
{
DerivedClass d = b as DerivedClass;
d. AMethodOnlyDerivedClassHas();

as you end up calling the same CLR support code twice.

An alternative would be to compare types, for example:

if ( b.GetType() == typeof( DerivedClass ) )

This is about 10 times as slow as using ‘as’ or ‘is’, but allows an exact comparison rather than the ‘at least’ comparison used by ‘as’ and just about everything else. In practice this is probably not useful though.

Getting Started

The idea is that this page will contain snippets I've gathered from my training and development work which will hopefully be useful to other developers.