C# versus C

Comparisons are invidious and therefore fun.

'Efficiency' is one of those wonderfully indefinite terms. C# is 'efficient' in putting a truly awesome array of resources at the command of the programmer. On the other paw, the further away you get from the machine in abstracting these resources, the more it costs in terms of pure 'machine' efficiencies of space and speed

The usual suspect is 'hello world', but apart from being boring this does not really have enough stuffing to support real-world comparisons.

So as a rough benchmark, I re-wrote a 'c' program that inspects an Excel spreadsheet for cells containing Unicode characters and replaces them with ascii characters in C#. Just pure IO and string handling.

Tbe run times were as follows:

  Language   Size   Load    Execution  = Total Time  Ratio
             Bytes  Time    Time        (Seconds)
  C#         10,240    6     222        = 228         144
  C          50,176    0   1.573        =   1.573       1

The load time includes JIT compilation from ILCode for the C# program. This becomes relatively more important for small execution times.

Execution times are from entering Main to exiting Main.

The C# program uses the OLE Excel object so this is as much a test of the automation object as C#.

It loads a range one cell at a time because I failed to persuade C# to inhale the whole sheet in one go, which would probably make it run a whole lot faster. I'm sure it could be written better.

The C program deals directly with the Excel spreadsheet file at the byte and bit level. It was a quick and dirty file format discovery program hack that was extended to handle the replacement task. Re-written efficiently it should run 2-4 times faster.

On the whole I would guess that if both were efficiently written the C:C# run time ratio would be something like 1 : 10-40.

Without getting into details on the memory footprints of the programs and their supporting DLL's we can note:

The 'c' program has the 'c' library statically bound in, and uses KERNEL.DLL.

The 'C#' program also uses the system DLL's, but in addition requires the CLR mscoredll.

A C# '.exe' is not standalone, but requires the Common Language Runtime (CLR) to be in place before it will give you the time of day.

.NET-compatible compilers do not translate source code into Win32 API calls, but instead into a special intermediate language, Microsoft Intermediate Language (MSIL).

When you 'execute' a C# program, the MSIL is streamed to the Common Language Runtime (CLR) which takes this intermediate language (IL) and, on the fly, does a Just In Time (JIT) compilation to x86 machine-specific instructions.

Jeffrey Richter's article on JIT Compilation and Performance : To NGen or Not to NGen? is required reading.

imho, Jeffrey's concern with rebasing is a bit overstated. This can be handled by segment fixups - see Pietrek : 'Liposuction your Executables'.