Microsoft MVP성태의 닷넷 이야기
.NET Framework: 614. C# - DateTime.Ticks의 정밀도 [링크 복사], [링크+제목 복사],
조회: 21129
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)

C# - DateTime.Ticks의 정밀도

지난 글에서,

윈도우 운영체제의 시간 함수 (1) - GetTickCount와 timeGetTime의 차이점
; https://www.sysnet.pe.kr/2/0/11063

윈도우 운영체제의 시간 함수 (2) - Sleep 함수의 동작 방식
; https://www.sysnet.pe.kr/2/0/11065

윈도우 운영체제의 시간 함수 (3) - QueryInterruptTimePrecise, QueryInterruptTime 함수
; https://www.sysnet.pe.kr/2/0/11066

윈도우 운영체제의 시간 함수 (4) - RTC, TSC, PM Clock, HPET Timer
; https://www.sysnet.pe.kr/2/0/11067

윈도우 운영체제의 시간 함수 (5) - TSC(Time Stamp Counter)와 QueryPerformanceCounter
; https://www.sysnet.pe.kr/2/0/11068

운영체제 수준에서 제공되는 시간 정밀도를 살펴봤는데요. 그럼, C#의 경우에는 어떻게 될까요? 오늘은 그 첫 번째로 DateTime.Ticks를 살펴보겠습니다.

간단하게 소스 코드를 보면, 답이 나오는데요.

[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern long GetSystemTimeAsFileTime();

public static DateTime UtcNow
{
    get
    {
        return new DateTime((ulong) ((GetSystemTimeAsFileTime() + 0x701ce1722770000L) | 0x4000000000000000L));
    }
}

다름 아닌 GetSystemTimeAsFileTime의 정밀도를 기반으로 만들어졌습니다. 이는 "Current timer interval"의 변화에 따라 정밀도가 변화한다는 것을 의미합니다. 즉, timeBeginPeriod/timeEndPeriod가 호출되지 않은 일반적인 윈도우 시스템의 15.625ms 기본 상태에서는 DateTime.Ticks 속성도 15.625ms 단위마다 시간이 바뀌게 된다는 것을 의미합니다.

실제로 다음과 같이 테스트해볼 수 있습니다.

using System;

class Program
{
    static void Main(string[] args)
    {
        int count = 100000;
        long[] tickBuf = new long[count];

        for (int i = 0; i < count; i++)
        {
            tickBuf[i] = DateTime.Now.Ticks;
        }

        long oldTime = tickBuf[0];
        long elapsed;
        for (int i = 1; i < count; i++)
        {
            elapsed = tickBuf[i] - oldTime;
            oldTime = tickBuf[i];

            if (elapsed != 0)
            {
                Console.WriteLine(elapsed);
            }
        }
    }
}

/*
출력 결과:

156292
*/

위에서 100,000번의 루프를 도는 동안 DateTime.Now.Ticks로 계속 시간을 재보지만 15.625ms의 타이머 간격을 가진 윈도우에서는 tickBuf 배열에 동일한 값만을 가지다가 어쩌다 시간이 바뀔 때가 되면 15.625에 가까운 시간 값이 출력됩니다.

위의 출력 결과에 보면 156,292값이 나오는데, DateTime.Ticks의 1은 100ns이므로 10,000으로 나누어 15.6292ms 값이 나옵니다. (대충 값이 비슷합니다.)

물론, timeBeginPeriod / timeEndPeriod로 clockres를 조절하면 다음과 같이 1ms 수준으로 정밀도를 낮출 수 있습니다.

using System;
using System.Runtime.InteropServices;

class Program
{
    [DllImport("winmm.dll", EntryPoint = "timeBeginPeriod")]
    public static extern uint timeBeginPeriod(uint uMilliseconds);

    [DllImport("winmm.dll", EntryPoint = "timeEndPeriod")]
    public static extern uint timeEndPeriod(uint uMilliseconds);

    static void Main(string[] args)
    {
        timeBeginPeriod(1);

        int count = 100000;
        long[] tickBuf = new long[count];

        for (int i = 0; i &lt; count; i++)
        {
            tickBuf[i] = DateTime.Now.Ticks;
        }

        long oldTime = tickBuf[0];
        long elapsed;
        for (int i = 1; i &lt; count; i++)
        {
            elapsed = tickBuf[i] - oldTime;
            oldTime = tickBuf[i];

            if (elapsed != 0)
            {
                Console.WriteLine(elapsed);
            }
        }

        timeEndPeriod(1);
    }
}
/*
출력 결과:

10013
9965
9992
10001
10007
10014
9989
10001
9998
10052
9941
10001
*/

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




정리하자면!

타이머 간격이 (기본 설정인) 15.625ms인 시스템을 기준으로, DateTime.Ticks로 특정 코드의 실행 성능을 재는 경우 15ms 이내에 수행되면 측정값이 0ms로 결과가 나올 수 있습니다. 또는, 운(?) 좋게 tick이 중간에 실행하는 경우 실제로 코드 수행에 소요된 시간은 2ms인데도 15ms 이상으로 나올 수 있는 부작용도 있습니다.

따라서, DateTime.Ticks로 실행 성능을 측정하고 싶다면 초 단위 수준(또는 적어도 100ms 정도)의 정밀도가 필요한 경우가 좋습니다.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/13/2023]

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

비밀번호

댓글 작성자
 



2019-03-21 11시25분
[Syong] 안녕하세요. 좋은 글 감사합니다.
질문사항이 있는데요, 말씀하신 대로라면 timeBeginPeriod / timeEndPeriod 이용해서 clockres 조절하면 DateTime.Ticks 이용해도 1ms도 무관한거 아닌가요?
QueryPerformancecounter를 사용하고 있는데, 많은 사용은 부하를 준다고 하여 tick으로 변경하려고 하는 중이라 문의드립니다.
[guest]
2019-03-21 10시39분
"1ms도 무관한 거"라는 것이 무슨 의미인가요?
정성태
2019-03-23 09시32분
[Syong] 마지막 말씀하신, "따라서, DateTime.Ticks로 실행 성능을 측정하고 싶다면 초 단위 수준(또는 적어도 100ms 정도)의 정밀도가 필요한 경우가 좋습니다. "에 대해서 질문드립니다. timeBeginPeriod / timeEndPeriod 이용해서 clockres 조절하면 1ms 수준의 정밀도를 요구하는 측정에 사용해도 상관없는 것 아닌가요?
[guest]
2019-03-23 10시14분
넵 당연히 조정하면 DateTime.Ticks로도 좋겠죠.
정성태

... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...
NoWriterDateCnt.TitleFile(s)
12556정성태3/9/20216904오류 유형: 703. PowerShell ISE의 Debug / Toggle Breakpoint 메뉴가 비활성 상태인 경우
12555정성태3/8/20218964Windows: 190. C# - 레지스트리에 등록된 DigitalProductId로부터 라이선스 키(Product Key)를 알아내는 방법파일 다운로드2
12554정성태3/8/20218795.NET Framework: 1027. 닷넷 응용 프로그램을 위한 PDB 옵션 - full, pdbonly, portable, embedded
12553정성태3/5/20219259개발 환경 구성: 548. 기존 .NET Framework 프로젝트를 .NET Core/5+ 용으로 변환해 주는 upgrade-assistant, try-convert 도구 소개 [4]
12552정성태3/5/20218527개발 환경 구성: 547. github workflow/actions에서 Visual Studio Marketplace 패키지 등록하는 방법
12551정성태3/5/20217445오류 유형: 702. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly. (2)
12550정성태3/5/20217104오류 유형: 701. Live Share 1.0.3713.0 버전을 1.0.3884.0으로 업데이트 이후 ContactServiceModelPackage 오류 발생하는 문제
12549정성태3/4/20217618오류 유형: 700. VsixPublisher를 이용한 등록 시 다양한 오류 유형 해결책
12548정성태3/4/20218360개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20218914오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218509개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111255.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111477.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/20219817VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112167개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219374개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219696.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219619Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202110016.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202111037.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202110024개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219143개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219757개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219374개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/20219890개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20218887개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...