calli IL 호출이 DllImport 호출보다 빠를까요?
네이티브 함수를 닷넷에서 직접 호출할 수 있는 IL 코드가 바로 calli인데요.
OpCodes.Calli Field
; https://learn.microsoft.com/en-us/dotnet/api/system.reflection.emit.opcodes.calli
예전에 OpenCover 코드 커버리지 도구를 살펴보면서 calli에 대한 동작 방식을 설명한 적도 있습니다. ^^
OpenCover 코드 커버리지 도구의 동작방식을 통해 살펴보는 Calli IL 코드 사용법
; https://www.sysnet.pe.kr/2/0/2882
근데... 이것이 일반적인 delegate 호출보다 성능이 더 좋다고 합니다.
Why is Calli Faster Than a Delegate Call?
; http://stackoverflow.com/questions/5893024/why-is-calli-faster-than-a-delegate-call
덧글에 보면 "The EmitCalli is faster because it is a raw byte code call"라고 하는데, 그럼 혹시 "
Managed to Unmanaged"간의 전환이 좀 더 가벼울 수도 있지 않을까요?
그래서, 가정을 해봤습니다. .NET에서 native 코드 호출 방법이 대표적으로 DllImport가 있는데요. 그것과 비교해 보면 어떨까요? 예제를 간단히 하기 위해
GetCurrentThreadId Win32 API를 대상으로 다음의 3가지 방법에 대해 각각 성능 테스트를 해봤습니다.
- C++ DLL 프로젝트에서 GetCurrentThreadId Win32 API의 주소를 반환해 calli로 호출하는 예제
- BCL에서 제공되는 AppDomain.GetCurrentThreadId를 호출하는 예제
- DllImport로 직접 kernel32.dll의 GetCurrentThreadId를 호출하는 예제
소스 코드는 대충 다음과 같습니다.
// ============== C++ DLL ==============
WIN32PROJECT1_API __int64 __stdcall fnWin32Project1()
{
return (__int64)&::GetCurrentThreadId;
}
// ============== C# DLL ==============
using System;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
namespace ClassLibrary1
{
[System.Security.SecuritySafeCritical]
public class Class1
{
[DllImport("Win32Project1.dll", EntryPoint = "fnWin32Project1")]
static extern long GetThisThreadId32();
static GetThisThreadIdDelegate _GetThisThreadIdMethod = null;
delegate int GetThisThreadIdDelegate();
static Class1()
{
long result = 0;
if (_GetThisThreadIdMethod == null)
{
if (IntPtr.Size == 4)
{
result = GetThisThreadId32();
}
var type = typeof(Class1);
DynamicMethod dynamicMethod = new DynamicMethod("", typeof(int), Type.EmptyTypes, type, true);
var iLGenerator = dynamicMethod.GetILGenerator();
if (IntPtr.Size == 4)
{
iLGenerator.Emit(OpCodes.Ldc_I4, (int)result);
}
else
{
iLGenerator.Emit(OpCodes.Ldc_I8, result);
}
iLGenerator.EmitCalli(OpCodes.Calli, CallingConvention.StdCall, typeof(int), Type.EmptyTypes);
iLGenerator.Emit(OpCodes.Ret);
GetThisThreadIdDelegate tempDelegate = dynamicMethod.CreateDelegate(typeof(GetThisThreadIdDelegate)) as GetThisThreadIdDelegate;
_GetThisThreadIdMethod = tempDelegate;
}
}
[System.Security.SecuritySafeCritical]
public static int GetThisThreadId()
{
try
{
return _GetThisThreadIdMethod();
}
catch
{
}
return 0;
}
}
}
// ============== C# EXE ==============
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
namespace ConsoleApplication1
{
class Program
{
[DllImport("kernel32.dll")]
static extern int GetCurrentThreadId();
static void Main(string[] args)
{
Action<int, string, Func<int>> action = (loopCount, title, work) =>
{
Stopwatch st = new Stopwatch();
st.Start();
Random rand = new Random(Environment.TickCount);
for (int i = 0; i < loopCount; i++)
{
work();
}
st.Stop();
Console.WriteLine(title + " : " + st.ElapsedTicks);
};
action(1, "touch-JIT", ClassLibrary1.Class1.GetThisThreadId);
action(1, "touch-JIT", AppDomain.GetCurrentThreadId); // 이 코드는 닷넷 프레임워크 환경에서 테스트한 것입니다. (참고: 닷넷 런타임에 따라 달라지는 AppDomain.GetCurrentThreadId의 반환값)
action(1, "touch-JIT", GetCurrentThreadId);
Console.WriteLine();
action(10000, "Calli", ClassLibrary1.Class1.GetThisThreadId);
action(10000, "BCL", AppDomain.GetCurrentThreadId);
action(10000, "DllImport", GetCurrentThreadId);
}
}
}
결과는 Calli가 코드가 복잡한 거에 비하면 감동적인 수준은 아니지만 그래도 빨라지긴 했습니다.
// x86 Release 빌드로 테스트 (낮을수록 좋음)
Calli : 851
BCL : 2170
DllImport : 1260
Calli : 843
BCL : 1303
DllImport : 1577
Calli : 881
BCL : 1445
DllImport : 1247
(
첨부한 파일은 위의 코드 테스트를 포함합니다.)
결론은, 성능을 조금이라도 개선할 필요가 있을 때만 calli 호출을 쓰시고 그 외에는 그냥 DllImport를 쓰시는 것이 좋습니다. 또는, 특수한 사례로 네이티브 코드를 제공할 때 symbol export가 안되도록 숨기고 싶은 경우에 한해 calli를 쓰는 것도 좋겠고. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]