This article provides a quick comparison between C++/CLI and C#. It’s meant for those who know C# (and possibly C++) and will explain which C++/CLI language construct correspond with which in C#. (I don’t know Visual Basic so I can’t add infos about this here.)

Note: This is not a complete reference but rather quick reference for those features that are (in my opinion) the most unclear.

Read more →

Today, while browsing some C++/CLI code, I stumbled upon several calls to GC.KeepAlive(someObj).

Immediately I thought memory leak – because I thought KeepAlive() would keep the object alive indefinitely.

Fortunately, this turned out to be wrong, though.

After reading the documentation of GC.KeepAlive() (couldn’t really figure it out), I did some decompiling and found out that GC.KeepAlive() looks like this:

1
2
3
4

[MethodImpl(MethodImplOptions.NoInlining)]
public static void KeepAlive(object obj)
{
}

It just does nothing. So what’s its purpose?

It’s there to fake an access to a variable.

Why? The .NET garbage collector may collect a variable directly after its last use – and not necessarily, contrary to common belief, at the end of the variable’s scope.

Consider this code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class SomeClass
{
  // This field is initialized somewhere 
  // in the constructor (not shown here).
  public SomeOtherClass Value;
 
  ...
}
 
...
 
void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  YetAnotherMethod();
  // obj still alive here? Possibly not.
}

The garbage collector may collect obj just after the runtime has retrieved obj.Value (line 15), i.e. before SomeOtherMethod() is even called.

Note: The exact line where obj will be marked for collection is up to the JIT compiler. The behavior describe above seems to be called “lookahead optimization”.

Usually this optimization not a problem. It becomes a problem, however, if SomeClass has a finalizer:

1
2
3
4
5
6
7
8
9
10
11

class SomeClass
{
  public SomeOtherClass Value;
 
  ~SomeClass()
  {
     // "Value" can't be used anymore 
     // after Dispose() has been called.
     this.Value.Dispose();
  }
}

So, if obj‘s finalizer is executed before SomeOtherMethod() is called, SomeOtherMethod() won’t be able to use obj.Value anymore.

To solve this problem, add GC.KeepAlive() after the call to SomeOtherMethod(), like this (line 5):

1
2
3
4
5
6
7

void MyMethod()
{
  SomeClass obj = new SomeClass();
  SomeOtherMethod(obj.Value);
  GC.KeepAlive(obj);
  YetAnotherMethod();
}

This way, the garbage collector won’t collect obj (and thus run its finalizer) before line 5 has been reached.

Notes:

• The implementation of the finalizer of SomeClass is flawed – as the examples in this article show. The user shouldn’t need to worry about Value being disposed too early.

  • Rule of thumb: A finalizer should only dispose the resources of its own class, not resources of some member (by calling Dispose() on members).
  • The problem with the finalizer persists if Value is an unmanaged resource/pointer that’s being passed to SomeOtherMethod(). This is always possible in C++/CLI. In C# Value could be of type IntPtr.
  • In the examples above, consider implementing and using IDisposable for SomeClass instead of GC.KeepAlive(), if you need a finalizer.
  • You still need to use GC.KeepAlive() if you can’t change the implementation of SomeClass.
• Using GC.KeepAlive() is like using GCHandle, just more light-weight and faster.

• GC.KeepAlive() only works because it can’t be inlined by the compiler (MethodImplOptions.NoInlining).

CodeProject

Just a quick overview over the different lock types and their performance in .NET.

For this test, the following method was called as fast as possible for 4 seconds:

private void TestMethod() {
  lock (this) { // this locking is replaced depending on the locking type
    counter++;
  }
}

Here are the results:

Full source code: Program.cs

For a project I was wondering what’s the performance penalty of using a C# struct (containing only one field) over using a local variable directly; i.e.:

int myVar;

vs.

struct MyStruct {
  int MyVar;
}

The result: There’s no (real) difference!

Here are some stats (“Release” build):

Running each test 50,000,000,000 times

Running 'UseLocalVar'...
Done in 61329.359 ms
Running 'UseStructField'...
Done in 61414.885 ms
Running 'UseStructProperty'...
Done in 121383.416 ms

The first two results are what I was talking about. The third result uses a property instead of a field in the struct. It’s two times slower.

Here’s the code for the benchmark:

using System;
using System.Diagnostics;

class Benchmark {
  const long LOOPS = 50000000000;

  static void Main(string[] args) {
    Benchmark benchmark = new Benchmark();

    Console.WriteLine("Running each test {0:0,0} times", LOOPS);
    Console.WriteLine();

    Console.WriteLine("Running 'UseLocalVar'...");
    Stopwatch stopWatch = Stopwatch.StartNew();
    int test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseLocalVar((int)x);
    }
    TimeSpan elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);


    Console.WriteLine("Running 'UseStructField'...");
    stopWatch = Stopwatch.StartNew();
    test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseStructField((int)x);
    }
    elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);


    Console.WriteLine("Running 'UseStructProperty'...");
    stopWatch = Stopwatch.StartNew();
    test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseStructProperty((int)x);
    }
    elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);
  }

  int UseLocalVar(int val) {
    int test = val;
    test = test + val;
    return test;
  }

  int UseStructField(int val) {
    TestStructField test = new TestStructField(val);
    test.Value = test.Value + val;
    return test.Value;
  }

  int UseStructProperty(int val) {
    TestStructProperty test = new TestStructProperty(val);
    test.Value = test.Value + val;
    return test.Value;
  }

  private struct TestStructField {
    public int Value;

    public TestStructField(int value) {
      this.Value = value;
    }
  }

  private struct TestStructProperty {
    public int Value { get; set; }

    public TestStructProperty(int value) : this() {
      this.Value = value;
    }
  }
}

P/Invoke is a way of calling C/C++ functions from a .NET program. It’s very easy to use. This article will cover the basics of using P/Invoke.

Note: This tutorial will focus on Windows and thus use Visual Studio. If you’re developing on another platform or with another IDE, adopting the things in this article should be easy enough.

Read more →