In Microsoft .NET Framework, if you want to access managed objects via native (unmanged) code, you have to 'pin' the managed objects since they may be "moved" to other places by the garbage collector. Here is some quotes from MSDN:
A pinning pointer ... that prevents the object pointed into from moving on the garbage-collected heap. This is necessary when passing the address of a managed class to an unmanaged function because the address will not change unexpectedly during resolution of the unmanaged function call. See More ...
In HnxGC system, objects by default are immovable unless you explicitly invoke system function to move them at a safe time. Therefore, you don't need to 'pin' an object and can directly pass the address to your native(unmanged) functions.
In this testing, we aim to measure and compare the cost of accessing managed data from a native(unmanged) function. Suppose we are writing a managed class to encapsulate BMP format pictures, the class will internally call native API functions to load and parse BMP format files, and put the image pixel data into a managed buffer. To simplify the testing, the size of image buffer is fixed at 400KB, and the BMP formating parsing and loading are replaced by a simple memset() call on part of the image buffer.
| Time Cost | |
|---|---|
| .NET pin_ptr | 1.10 ~ 1.12 s |
| HnxGC | 5 ~ 6 ms |
From this testing result, the performance of calling a native function in HnxGC is much faster than using a pin_ptr in .NET framework. So, if you are not feeling 100% satisfied about the performance of your managed HnxGC code, you can rewrite some of them in native code. The communication cost between native and managed codes is so low that you are free to call native functions as you like. There is no more worries about the `pin_ptr' cost as in the Microsoft .NET framework.
Click to see the output logs: .NET CLR, HnxGC
download the source code of this testing.
case2-hnx.cpp
case2-clr.cpp
Makefile