Microsoft MVP성태의 닷넷 이야기
.NET Framework: 517. calli IL 호출이 DllImport 호출보다 빠를까요? [링크 복사], [링크+제목 복사],
조회: 23514
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

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가지 방법에 대해 각각 성능 테스트를 해봤습니다.

  1. C++ DLL 프로젝트에서 GetCurrentThreadId Win32 API의 주소를 반환해 calli로 호출하는 예제
  2. BCL에서 제공되는 AppDomain.GetCurrentThreadId를 호출하는 예제
  3. 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를 쓰는 것도 좋겠고. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/20/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2020-02-27 10시25분
{
    // public delegate void VoidIntPtrDelegate(IntPtr objAddress);

    var type = typeof(Program);
    DynamicMethod dynamicMethod = new DynamicMethod("", typeof(void), new Type[] { typeof(IntPtr) }, type, true);

    var iLGenerator = dynamicMethod.GetILGenerator();

    iLGenerator.Emit(OpCodes.Ldarg_0);

    if (IntPtr.Size == 4)
    {
        iLGenerator.Emit(OpCodes.Ldc_I4, ...32비트 코드 주소...);
    }
    else
    {
        iLGenerator.Emit(OpCodes.Ldc_I8, ...645비트 코드 주소...);
    }

    iLGenerator.EmitCalli(OpCodes.Calli, CallingConvention.StdCall, typeof(void), new Type[] { typeof(IntPtr) });
    iLGenerator.Emit(OpCodes.Ret);

    VoidIntPtrDelegate tempDelegate = dynamicMethod.CreateDelegate(typeof(VoidIntPtrDelegate)) as VoidIntPtrDelegate;
}
정성태

... 91  92  93  94  95  96  97  98  99  100  101  102  103  [104]  105  ...
NoWriterDateCnt.TitleFile(s)
11365정성태11/25/201722082오류 유형: 429. 이벤트 로그 - User Policy could not be updated successfully
11364정성태11/24/201724774사물인터넷: 11. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스로 쓰는 방법 (절대 좌표) [2]
11363정성태11/23/201724704사물인터넷: 10. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스 + 키보드로 쓰는 방법 (두 번째 이야기)
11362정성태11/22/201720401오류 유형: 428. 윈도우 업데이트 KB4048953 - 0x800705b4 [2]
11361정성태11/22/201723379오류 유형: 427. 이벤트 로그 - Filter Manager failed to attach to volume '\Device\HarddiskVolume??' 0xC03A001C
11360정성태11/22/201723845오류 유형: 426. 이벤트 로그 - The kernel power manager has initiated a shutdown transition.
11359정성태11/16/201723107오류 유형: 425. 윈도우 10 Version 1709 (OS Build 16299.64) 업그레이드 시 발생한 문제 2가지
11358정성태11/15/201728110사물인터넷: 9. Visual Studio 2017에서 Raspberry Pi C++ 응용 프로그램 제작 [1]
11357정성태11/15/201728570개발 환경 구성: 336. 윈도우 10 Bash 쉘에서 C++ 컴파일하는 방법
11356정성태11/15/201730122사물인터넷: 8. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스 + 키보드로 쓰는 방법 [4]
11355정성태11/15/201725316사물인터넷: 7. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스로 쓰는 방법 [2]파일 다운로드2
11354정성태11/14/201730150사물인터넷: 6. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 키보드로 쓰는 방법 [8]
11353정성태11/14/201727134사물인터넷: 5. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 이더넷 카드로 쓰는 방법 [1]
11352정성태11/14/201723457사물인터넷: 4. Samba를 이용해 윈도우와 Raspberry Pi간의 파일 교환 [1]
11351정성태11/7/201726362.NET Framework: 698. C# 컴파일러 대신 직접 구현하는 비동기(async/await) 코드 [6]파일 다운로드1
11350정성태11/1/201722423디버깅 기술: 108. windbg 분석 사례 - Redis 서버로의 호출을 기다리면서 hang 현상 발생
11349정성태10/31/201723093디버깅 기술: 107. windbg - x64 SOS 확장의 !clrstack 명령어가 출력하는 Child SP 값의 의미 [1]파일 다운로드1
11348정성태10/31/201719275디버깅 기술: 106. windbg - x64 역어셈블 코드에서 닷넷 메서드 호출의 인자를 확인하는 방법
11347정성태10/28/201723055오류 유형: 424. Visual Studio - "클래스 다이어그램 보기" 시 "작업을 완료할 수 없습니다. 해당 인터페이스를 지원하지 않습니다." 오류 발생
11346정성태10/25/201719703오류 유형: 423. Windows Server 2003 - The client-side extension could not remove user policy settings for 'Default Domain Policy {...}' (0x8007000d)
11338정성태10/25/201717295.NET Framework: 697. windbg - SOS DumpMT의 "BaseSize", "ComponentSize" 값에 대한 의미파일 다운로드1
11337정성태10/24/201719836.NET Framework: 696. windbg - SOS DumpClass/DumpMT의 "Vtable Slots", "Total Method Slots", "Slots in VTable" 값에 대한 의미파일 다운로드1
11336정성태10/20/201721125.NET Framework: 695. windbg - .NET string의 x86/x64 메모리 할당 구조
11335정성태10/18/201719911.NET Framework: 694. 닷넷 - <Module> 클래스의 용도
11334정성태10/18/201720638디버깅 기술: 105. windbg - k 명령어와 !clrstack을 조합한 호출 스택을 얻는 방법
11333정성태10/17/201719987오류 유형: 422. 윈도우 업데이트 - Code 9C48 Windows update encountered an unknown error.
... 91  92  93  94  95  96  97  98  99  100  101  102  103  [104]  105  ...