. Net short talk about interoperability (6: Improving platform calling performance based on basic knowledge)

Interoperability Series Article :

1. . Net short talk about interoperability (1: Introduction At the beginning)
2. . Net short talk about interoperability (2: Faster first)
3. . Net short talk about interoperability (3: Basic knowledge of dllimport features)
4. . Net short talk about interoperability (4: Basic knowledge-based dispose unmanaged memory)
5. . Net short talk about interoperability (5: Basic knowledge-based dynamic platform call)
6. . Net short talk about interoperability (6: Improving platform calling performance based on basic knowledge)
7. . Net short talk about interoperability (7: Introduction to data sending)

We continue to learn about. Net interoperability. In this article, we will learn the last knowledge point in the basic knowledge of interoperability, "Improving the Performance of Platform calls ";

Because of the large number of technical factors involved in the process of interoperability of unmanaged functionsProgramPerformance will be affected by these factors, leading to performance degradation. This article will introduce some design and coding skills to improve the performance of the platform call process in the future;[Wang qingpei has all rights reserved. For more information, please sign it.]

I. The name of the unmanaged function to be called is displayed.

When we call the platform, if the CLR cannot find an unmanaged function with the same name as the function specified by the dllimport feature in an unmanaged DLL, then the CLR will try to use some rules to re-search. For example, we declare the charset of the Suma unmanaged function as charset. ANSI, the CLR first searches through the root function name (SUM). If this function is found in the specified Unmanaged DLL, it is used. If it cannot be found, a function (SUMA) with the suffix A will be used for search. In fact, the reason for this is the difference in character encoding. Some Function implementations adopt the ANSI method and some adopt the Unicode method, the differences between the two encoding methods ultimately lead to different data storage in the memory. Therefore, we need to pay attention to the issue of unmanaged calls;

UnmanagedCode:

Extern "C" _ declspec (dllexport) int _ stdcall Adda (int x, int y)
{
Return X + Y;
}

Managed code Statement 1:

[Dllimport ("win32dll. dll", entrypoint = "add", charset = charset. ANSI, callingconvention = callingconvention. stdcall)]
Public static extern int add (int x, int y );

Managed code Statement 2:

[Dllimport ("win32dll. dll", entrypoint = "Adda", charset = charset. ANSI, callingconvention = callingconvention. stdcall, exactspelling = true)]
Public static extern int add (int x, int y );

The above two managed code statements are slightly different. The first managed code is our common declarative method, and the second is our rare declarative method, two different declarative methods are different for CLR Platform calls, and the calling process is slightly different. The second declarative method can improve the performance; in the second code statement, exactspelling = true (explicitly specifying the name of the unmanaged function to be called) appears, we force use the method entry point affirmed by entrypoint. CLR is not allowed to help us dynamically adjust the function name to find the entry name, which saves the CLR search time;

Ii. Optimize data sending and sealing

When passing parameters between managed code and non-managed code, both pass-in and pass-out must be handled by the mail collector. Since the sending process may involve data type conversion and data replication between unmanaged memory and non-hosted memory, sending and receiving is also one of the bottlenecks affecting the platform calling performance.

When sending data to the CLR, there are only two options: Lock data or copy data. By default, CLR will copy data during the sending process. If we need to pass a unicode string as ANSI to unmanaged code, first, CLR copies the string, converts the copied string to ANSI, and then transmits the memory address of the converted ANSI string to the unmanaged code; since copying data may be a waste of time, sending data is also one of the bottlenecks affecting performance;

There is also a way to lock the memory for data sending, which means that the CLR can directly lock the hosted object to the garbage collection stack, and prevent the managed object from being recycled within the function call lifecycle, once the managed object is locked, you can directly pass the pointer to the managed object to the unmanaged code, so as to avoid data copying and optimization;

But not all data types can be locked. To be locked, you must have some platform-related conventions. We can see that only the objects that meet these conditions can be locked by CLR;

1. It must be managed code that calls the unmanaged code, that is, the local code;

2. The managed data type must be the data type that can be directly copied to the machine structure (blittable), or be able to convert the Data Type of the cost machine structure under certain conditions;

3. The parameter passed is not a reference (ref, out) parameter;

4. The called code and the called code must be in the same thread context or thread unit;

After the summary above, we can find that to reduce the data replication operation of the mail collector, we can use the local structure type for transmission, the local schema type is exactly the same in the hosted memory and in the unmanaged memory.[Wang qingpei has all rights reserved. For more information, please sign it.]

Therefore, when preparing the development platform calling program, we should try our best to consider using the local data structure; for example: system. byte: Unsigned 8-bit integer, system. sbyte: signed 8-bit integer;

Summary: As this article involves the relevant technologies of data sending, we will soon end our learning of the basic part. Next we will learn about the technologies related to interoperability data sending;