GetTickCount()나 mmTimer를 이용하는 방법, C런타임 라이브러리를 이용하는 방법등 많이 있으나, 그중 한가지는.
LARGE_INTEGER st, ed, freq;
double gap;
QueryPerformanceCounter(&st);
// 뭔가 성능을 측정할 작업을 한다.
QueryPerformanceCounter(&ed);
QueryPerformanceFrequency(&freq);
gap = ((double)(ed.QuadPart - st.QuadPart)) / ((double)freq.QuadPart);
여기서 gap을 출력하면 초단위로 잰 시간이 나옵니다.
출력값이 double이므로 초단위가 마음에 들지 않으시면, 적절히 스케일링 해 주시면 되겠지요.
사족이지만 예전에 win98이 50일째 다운되는 버그가 있었다는데 이게 아닐까
생각해봅니다. 98 SE부터는 해결됐다는데... ㅎㅎ;
그리고 이런 신으로 오버플로되는 것은 리눅스의 지피값도 마찬가지죠.
다만 리눅스 지피값이 msec이 아니기 때문이 오버플로 되는 주기는 윈도
보다는 훨씬 길죠.
간단한 루틴의 실행 속도를 측정하기 위해 사용하기에는 GetTickCount()가
, 그러니까 1msec이 너무 크죠. (세상에나... ^^;) 전 그냥 수만번 루프 돌리고
맙니다만..... 요즘엔 초당 n번 실행되는 루틴을 테스트하는데 귀찮아서 그냥
CPU 점유율 확인합니다. -.-; 의도적으로 오버헤드 안주면 0%나오지만... -.-;;
--------------------------------------
재미없는 일은 하지 말자는 인간 쓰레기.
-.-;
QueryPerformanceFrequencyQueryPerforma
QueryPerformanceFrequency
QueryPerformanceCounter
이거면 충분하지 않을까요? 더 정밀한 걸 원하신다면 CPU 종속이긴 하지만, 레지스터에 파워온 다음부터의 내부 카운터를 넘겨주는 명령이 있긴 합니다.
그럼, 이만...
많은 방법들이 있습니다만.
GetTickCount()나 mmTimer를 이용하는 방법, C런타임 라이브러리를 이용하는 방법등 많이 있으나, 그중 한가지는.
여기서 gap을 출력하면 초단위로 잰 시간이 나옵니다.
출력값이 double이므로 초단위가 마음에 들지 않으시면, 적절히 스케일링 해 주시면 되겠지요.
앗 방금 수정하셨네요.그럼, 총총...
앗 방금 수정하셨네요.
그럼, 총총...
GetTickCount는 권장하고 싶지 않군요.
GetTickCount 는 32bit 이라서 7일 정도에 한번 reset 됩니다. 그래서 권하고 싶지는 않습니다.
GetTickCount()가 32비트값을 리턴하기는 하지만
msec 단위를 리턴하기 때문에 주기는 7일이 아니라 49.x 일입니다.
사족이지만 예전에 win98이 50일째 다운되는 버그가 있었다는데 이게 아닐까
생각해봅니다. 98 SE부터는 해결됐다는데... ㅎㅎ;
그리고 이런 신으로 오버플로되는 것은 리눅스의 지피값도 마찬가지죠.
다만 리눅스 지피값이 msec이 아니기 때문이 오버플로 되는 주기는 윈도
보다는 훨씬 길죠.
간단한 루틴의 실행 속도를 측정하기 위해 사용하기에는 GetTickCount()가
, 그러니까 1msec이 너무 크죠. (세상에나... ^^;) 전 그냥 수만번 루프 돌리고
맙니다만..... 요즘엔 초당 n번 실행되는 루틴을 테스트하는데 귀찮아서 그냥
CPU 점유율 확인합니다. -.-; 의도적으로 오버헤드 안주면 0%나오지만... -.-;;
--------------------------------------
재미없는 일은 하지 말자는 인간 쓰레기.
-.-;
앗~~ 감사함다
답변 달아주신 분들 모두 감사드리고 특히 mrchu 님 감사합니다.
덕분에 좋은 결과값을 얻을수 있었습니다. 감사합니다.
^^
댓글 달기