Microsoft MVP성태의 닷넷 이야기
.NET Framework: 614. C# - DateTime.Ticks의 정밀도 [링크 복사], [링크+제목 복사],
조회: 29684
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 8개 있습니다.)
.NET Framework: 614. C# - DateTime.Ticks의 정밀도
; https://www.sysnet.pe.kr/2/0/11082

.NET Framework: 827. C# - 인터넷 시간 서버로부터 받은 시간을 윈도우에 적용하는 방법
; https://www.sysnet.pe.kr/2/0/11883

스크립트: 33. JavaScript와 C#의 시간 변환
; https://www.sysnet.pe.kr/2/0/12849

Windows: 204.  Windows 10부터 바뀐 QueryPerformanceFrequency, QueryPerformanceCounter
; https://www.sysnet.pe.kr/2/0/13035

.NET Framework: 1997. C# - nano 시간을 가져오는 방법
; https://www.sysnet.pe.kr/2/0/13036

스크립트: 47. 파이썬의 time.time() 실숫값을 GoLang / C#에서 사용하는 방법
; https://www.sysnet.pe.kr/2/0/13308

닷넷: 2143. C# - 시스템 Time Zone 변경 시 이벤트 알림을 받는 방법
; https://www.sysnet.pe.kr/2/0/13413

닷넷: 2309. C# - .NET Core에서 바뀐 DateTime.Ticks의 정밀도
; https://www.sysnet.pe.kr/2/0/13803




C# - DateTime.Ticks의 정밀도

(이 글은 .NET Framework 환경에서 유효합니다. .NET Core 버전인 경우는 C# - .NET Core에서 바뀐 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를 살펴보겠습니다.

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

// .NET Framework

[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 단위마다 시간이 바뀌게 된다는 것을 의미합니다.

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

// .NET Framework

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 수준으로 정밀도를 낮출 수 있습니다.

// .NET Framework

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 < 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);
            }
        }

        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/7/2024]

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로도 좋겠죠.
정성태

... 46  47  48  49  [50]  51  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12688정성태6/24/202117658.NET Framework: 1073. C# - JSON 역/직렬화 시 리플렉션 손실을 없애는 JsonSrcGen [2]파일 다운로드1
12687정성태6/22/202114981오류 유형: 729. Invalid data: Invalid artifact, java se app service only supports .jar artifact
12686정성태6/21/202116944Java: 22. Azure - 자바(Java)로 만드는 Web App Service - Java SE (Embedded Web Server) 호스팅
12685정성태6/21/202118160Java: 21. Azure Web App Service에 배포된 Java 프로세스의 메모리 및 힙(Heap) 덤프 뜨는 방법
12684정성태6/19/202116506오류 유형: 728. Visual Studio 2022부터 DTE.get_Properties 속성 접근 시 System.MissingMethodException 예외 발생
12683정성태6/18/202117830VS.NET IDE: 166. Visual Studio 2022 - Windows Forms 프로젝트의 x86 DLL 컨트롤이 Designer에서 오류가 발생하는 문제 [1]파일 다운로드1
12682정성태6/18/202114370VS.NET IDE: 165. Visual Studio 2022를 위한 Extension 마이그레이션
12681정성태6/18/202114658오류 유형: 727. .NET 2.0 ~ 3.5 + x64 환경에서 System.EnterpriseServices 참조 시 CS8012 경고
12680정성태6/18/202116714오류 유형: 726. python2.7.exe 실행 시 0xc000007b 오류
12679정성태6/18/202116822COM 개체 관련: 23. CoInitializeSecurity의 전역 설정을 재정의하는 CoSetProxyBlanket 함수 사용법파일 다운로드1
12678정성태6/17/202115319.NET Framework: 1072. C# - CoCreateInstance 관련 Inteop 오류 정리파일 다운로드1
12677정성태6/17/202118103VC++: 144. 역공학을 통한 lxssmanager.dll의 ILxssSession 사용법 분석파일 다운로드1
12676정성태6/16/202117278VC++: 143. ionescu007/lxss github repo에 공개된 lxssmanager.dll의 CLSID_LxssUserSession/IID_ILxssSession 사용법파일 다운로드1
12675정성태6/16/202115168Java: 20. maven package 명령어 결과물로 (war가 아닌) jar 생성 방법
12674정성태6/15/202116419VC++: 142. DEFINE_GUID 사용법
12673정성태6/15/202117036Java: 19. IntelliJ - 자바(Java)로 만드는 Web App을 Tomcat에서 실행하는 방법
12672정성태6/15/202118657오류 유형: 725. IntelliJ에서 Java webapp 실행 시 "Address localhost:1099 is already in use" 오류
12671정성태6/15/202127326오류 유형: 724. Tomcat 실행 시 Failed to initialize connector [Connector[HTTP/1.1-8080]] 오류
12670정성태6/13/202117302.NET Framework: 1071. DLL Surrogate를 이용한 Out-of-process COM 개체에서의 CoInitializeSecurity 문제파일 다운로드1
12669정성태6/11/202117497.NET Framework: 1070. 사용자 정의 GetHashCode 메서드 구현은 C# 9.0의 record 또는 리팩터링에 맡기세요.
12668정성태6/11/202119999.NET Framework: 1069. C# - DLL Surrogate를 이용한 Out-of-process COM 개체 제작파일 다운로드2
12667정성태6/10/202117793.NET Framework: 1068. COM+ 서버 응용 프로그램을 이용해 CoInitializeSecurity 제약 해결파일 다운로드1
12666정성태6/10/202115442.NET Framework: 1067. 별도 DLL에 포함된 타입을 STAThread Main 메서드에서 사용하는 경우 CoInitializeSecurity 자동 호출파일 다운로드1
12665정성태6/9/202117496.NET Framework: 1066. Wslhub.Sdk 사용으로 알아보는 CoInitializeSecurity 사용 제약파일 다운로드1
12664정성태6/9/202115292오류 유형: 723. COM+ PIA 참조 시 "This operation failed because the QueryInterface call on the COM component" 오류
12663정성태6/9/202117672.NET Framework: 1065. Windows Forms - 속성 창의 디자인 설정 지원: 문자열 목록 내에서 항목을 선택하는 TypeConverter 제작파일 다운로드1
... 46  47  48  49  [50]  51  52  53  54  55  56  57  58  59  60  ...