Windows에서 서로 다른 버전의 프로그램의 실행 속도를 어떻게 비교할까. 전원 모드 등 환경을 맞추는 방법부터 한계까지

Windows에서 프로그램의 버전 A와 B를 비교하고 싶다.
그때 가장 해서는 안 되는 것은 같은 머신에서 1회씩 실행하고 「B 쪽이 8% 빠른 듯」이라고 말해 버리는 것입니다.

그 8%는 정말로 코드 차일지도 모릅니다.
하지만 실제로는 전원 모드, power plan, 열, 백그라운드 갱신, 검색 인덱스, 바이러스 스캔, 어피니티, 실행 순서, 캐시 상태 중 어느 것이었다는 것이 Windows 벤치의 흔한 일입니다. 꽤 진흙투성이의 세계입니다.

이 글에서는 Windows 상에서 서로 다른 버전의 프로그램의 실행 속도를 가능한 한 코드 차에 가까운 형태로 비교하는 방법을 정리합니다.
대상은 주로 Windows 11을 상정하고 있지만 powercfg나 start 등의 대부분은 Windows 10에서도 마찬가지로 쓸 수 있습니다.

먼저 결론

먼저 결론만 말하면 재현성을 높이는 요령은 다음 6가지입니다.

「무엇을 비교하고 싶은가」를 먼저 정한다
코드 차를 보고 싶은가, 실사용자 체감을 보고 싶은가에 따라 맞춰야 할 환경이 바뀝니다.
power mode와 power plan을 별개로 기록한다
Windows에서는 여기를 거칠게 다루면 비교가 OS의 절전 방침 비교가 되기 쉽습니다.
차가운 1회째와 따뜻해진 뒤의 정상 상태를 나눈다
초회만 빠름·후반만 느림은 드물지 않습니다.
A→B→A→B처럼 교대로 돌린다
A를 먼저 전부 돌리고 나서 B를 돌리면 열이나 백그라운드 상태의 편향을 떠안습니다.
평균뿐만 아니라 중앙값과 산포를 본다
1개의 이상치로 세계관이 무너집니다. 평균은 생각보다 무릅니다.
차가 작다면 ETW / WPR로 원인까지 판다
체감으로 논의하면 대체로 안갯속에서 맞붙게 됩니다.

무엇을 비교하고 싶은지를 먼저 정한다

「속도 비교」라고 하지만 실은 2종류가 있습니다.

1. 코드 차를 보고 싶은 비교

알고리즘 변경, 데이터 구조 변경, 컴파일러 최적화, 런타임 갱신 등에 의해 구현 그 자체가 빨라졌는가를 알고 싶은 비교입니다.

이 경우는 환경 노이즈를 가능한 한 깎습니다.
벤치 전용 세션, power mode 고정, 통지 정지, 검색 인덱스나 동기의 억제, 필요하다면 clean boot까지 합니다.

2. 실사용자 체감을 보고 싶은 비교

배포 후에 사용자가 평소의 Windows 상에서 체감하는 속도를 알고 싶은 비교입니다.

이 경우는 현실에 존재하는 노이즈를 전부 지워서는 안 됩니다.
OneDrive 동기, Defender, 통지, 통상의 전원 설정 등을 포함한 「그럴듯한 일상 환경」에서 비교하는 편이 현실에 가까운 결과가 됩니다.

이 2가지를 섞으면 결론이 뒤틀립니다.
「랩에서는 12% 빠른데 현실에서는 오차」「현실에서는 빠른데 CPU 시간으로는 바뀌지 않음」 같은 일이 평범하게 일어납니다.

Windows에서 결과가 흔들리는 주된 요인

우선 무엇이 결과를 흔드는지를 거칠게 일람화해 둡니다.

층	흔들림 요인	전형 예
하드웨어	CPU / GPU, 메모리, SSD, 냉각	노트 PC의 얇음, 냉각대의 유무
펌웨어	BIOS / UEFI, OEM 제어	절전 정책, 팬 제어
OS	Windows build, 드라이버, 갱신 상태	같은 PC여도 갱신 후에 동작이 바뀜
전원	AC / DC, power mode, power plan	배터리 구동이면 별세계
열	실온, 팬, 직전의 부하	1회째만 터보, 후반에 실속
백그라운드	Update, Defender, 동기, 통지	실행 중에 스캔이나 동기가 달림
스케줄링	우선도, 어피니티, NUMA	머신에 따라 CPU 배치가 바뀜
데이터 / 캐시	OS 캐시, 앱 캐시	초회만 느림, 2회째 이후만 빠름
빌드 조건	Debug / Release, PGO, 로그 유무	애초에 다른 것을 비교하고 있음

요컨대 「같은 Windows 머신」이어도 조건이 갖춰져 있지 않으면 다른 실험입니다.

power mode와 power plan은 나누어 생각한다

여기는 꽤 중요합니다.

Windows에는 설정 앱의 Power mode와 종래의 Power plan(powercfg로 보이는 전원 플랜)이 있습니다.
겉보기가 비슷하므로 한데 묶이기 쉽지만, 거칠게 다루면 비교가 엉망이 됩니다.

Windows의 설정 앱에서는 Settings > System > Power & battery에서 Power mode를 고를 수 있습니다.
Microsoft의 문서에서는 Plugged in / On Battery마다 Best power efficiency, Balanced, Best performance를 전환할 수 있다고 되어 있습니다. 또한 Power mode는 바뀌면 배후의 전원 관련 설정이나 PPM(Processor Power Management)의 동작에도 영향을 미칩니다. 즉 여기가 다른 것만으로 코어 주차나 성능 스케일링의 방침이 바뀔 수 있습니다.

한편 Power plan은 Balanced, High performance 같은 전통적인 전원 플랜입니다.
powercfg /list나 powercfg /getactivescheme로 확인할 수 있습니다.

여기서 까다로운 것은 Windows에는 power mode의 오버레이와 power plan의 양쪽이 있는 것입니다.
그래서 벤치 결과에는 최소한 다음을 기록해 주세요.

AC인가 배터리인가
Power mode가 무엇인가
Active power plan이 무엇인가

이 3가지를 쓰지 않은 벤치 결과는 나중에 보면 꽤 괴롭습니다.

우선 고정해야 할 전원 조건

노트 PC는 반드시 AC 접속으로 비교한다
배터리 운영은 의도하지 않은 제한이 들어가기 쉽습니다.
Power mode를 고정한다
벤치 용도라면 먼저 Best performance를 시도합니다.
Active power plan을 기록한다
powercfg로 현재값을 남깁니다.

powercfg /list
powercfg /getactivescheme

필요하다면 High performance로 전환한다

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

「High performance가 나오지 않는다」는 평범하게 있다

여기도 빠지는 곳입니다.
Microsoft의 문서에서는 Modern Standby 대응 디바이스에서는 Balanced 또는 Balanced에서 파생된 플랜밖에 허가되지 않는다고 되어 있습니다.
그래서 「High performance가 안 보인다, 망가졌나?」가 아니라 그 기종의 설계상 그렇게 되어 있는 가능성이 있습니다.

또한 Microsoft는 「Power mode를 변경할 수 없는 경우 custom power plan이 선택되고 있을지도 모르니 먼저 Balanced를 선택해 본다」고 안내하고 있습니다. Power mode의 UI가 움직이지 않을 때는 여기를 의심하는 것이 빠릅니다.

백그라운드 노이즈를 뭉갠다

Windows는 부지런합니다. 이쪽이 조용히 벤치하고 싶을 때에도 뒤에서 여러 가지 해 줍니다.

먼저 재기동해서 안정될 때까지 기다린다

설정 변경 후에는 한 번 재기동하고, 로그인 후 바로 달리지 말고 몇 분 기다립니다.
기동 직후에는 갱신, 인덱스, 동기, Defender, 각종 상주가 아직 날뛰고 있습니다.

serious한 비교라면 clean boot를 쓴다

Microsoft는 clean boot에 의해 최소한의 스타트업 구성으로 할 수 있는 절차를 안내하고 있습니다.
msconfig로 Microsoft 이외의 서비스를 멈추고, Task Manager로 Startup apps를 무효화하는 방법입니다.

이것은 노이즈를 줄이는 데는 강력합니다.
다만 일상 이용 환경과는 떨어지므로, 「코드 차를 보기 위한 랩 비교」에서 쓰는 것이 맞습니다.

통지를 조용하게 한다

Windows의 통지 배너는 가볍게 보여도 의외로 방해입니다.
시각적으로 방해일 뿐만 아니라 실행 타이밍이나 포커스, 뒤의 앱 활동을 바꾸는 경우가 있습니다.

Do not disturb를 수동으로 유효화하거나 적어도 벤치 중에는 통지를 끕니다.

검색 인덱스와 동기를 억제한다

벤치 대상이 대량 파일을 읽는, 생성물을 대량으로 쓰는, 소스 트리를 몇 번이나 다시 만드는 타입이라면 검색 인덱스나 클라우드 동기가 수수하게 찔립니다.

벤치용 디렉토리를 검색 대상에서 뺀다
OneDrive / Dropbox / Google Drive 등의 동기를 멈춘다
브라우저, Teams, Discord, Slack을 닫는다

이쯤은 화려함은 없지만 효과가 있을 때는 꽤 효과가 있습니다.

열을 맞추지 않는 비교는 대체로 열을 비교하고 있다

CPU나 GPU는 차가울 때와 따뜻해진 뒤에는 다른 생물이 됩니다.
특히 노트 PC, 박형 미니 PC, 소형 데스크톱은 현저합니다.

지켜야 할 규칙

실온을 가능한 한 맞춘다
노트 PC의 놓는 방식을 고정한다
AC 어댑터, 도크, 외부 디스플레이 구성을 고정한다
벤치 전에 무거운 작업을 하지 않는다
초회 실행과 정상 상태를 나누어 측정한다

실행 순서는 교대로

A를 10회 하고 나서 B를 10회는 피합니다.
열, 캐시, 백그라운드 활동의 편향이 실리기 때문입니다.

추천은 다음 중 어느 것입니다.

A B A B A B ...
A B B A A B B A ...
랜덤 순서를 사전 생성하고 그 순서로 돈다

무엇을 측정하는가로 「빠름」의 의미는 바뀐다

「빠름」을 하나의 숫자에 밀어 넣으면 대체로 사고가 납니다.
Windows에서 봐야 할 대표적인 지표는 다음 3가지입니다.

1. Wall-clock time(실시간)

사용자가 기다리는 시간입니다.
엔드 투 엔드의 체감에 가장 가까우므로 우선 처음에 보는 값은 이것입니다.

Windows에서는 QueryPerformanceCounter(QPC)가 고분해능의 시각 취득에 쓸 수 있습니다.
managed code라면 Stopwatch 계를 쓰는 것이 기본입니다.
DateTime.Now로 밀리초를 보는 것은 과연 조금 무방비입니다.

2. CPU time(사용자 + 커널 시간)

GetProcessTimes로 취득할 수 있는, 프로세스가 실제로 CPU를 쓴 시간입니다.

이것은 계산 효율을 보는 데 편리합니다.
예를 들어 wall-clock에서는 빨라졌는데 CPU time이 바뀌지 않았다면 캐시, I/O, 대기 시간, 스케줄링이 효과를 내고 있을 가능성이 있습니다.

3. Cycle count(CPU 사이클 수)

QueryProcessCycleTime으로 프로세스 전체의 CPU 사이클 수를 취할 수 있습니다.

이것도 CPU work를 보는 지표지만, wall-clock과는 다른 면을 보여 줍니다.
특히 「대기 시간은 같은데 계산 부분은 가벼워지고 있는가」를 보고 싶을 때 편리합니다.

priority, affinity, NUMA는 마지막 수단

이쯤은 효과가 있을 때가 있습니다.
하지만 효과가 있다고 해서 처음부터 만지면 다른 현상을 만들기 쉽습니다.

우선 평범하게 측정한다

기본 상태에서 차가 난다면 그 차 자체에 가치가 있습니다.
갑자기 /high나 /affinity를 넣으면 「실제 Windows에서는 일어나지 않는 조건」을 들이게 됩니다.

쓴다면 목적을 명확히 한다

/high: 다른 프로세스의 방해를 받기 어렵게 하고 싶다
/affinity: CPU 배치를 고정해 비교하고 싶다
NUMA 제어: 대규모 머신에서 메모리 국소성까지 맞추고 싶다

Windows의 start 커맨드는 priority class나 affinity mask를 붙여 기동할 수 있습니다.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

다만 /realtime은 그만둔다

/realtime은 쓸 수 있지만 쓰지 않는 편이 좋습니다.
노이즈 제거가 아니라 다른 사고를 만드는 방향으로 작용하기 쉽습니다.

측정 절차의 추천

여기까지를 근거로 한 실운용하기 쉬운 절차를 정리합니다.

랩 쪽의 비교 절차

비교 대상을 고정한다
- commit hash / build number
- compiler / runtime version
- Debug / Release
- 로그, assert, 트레이스 유무
머신 조건을 고정한다
- Windows build
- BIOS / UEFI version
- driver version
- AC 접속
- 실온, 설치 방법
전원 조건을 고정한다
- Power mode를 정한다
- Active power plan을 기록한다
재기동한다
벤치 전에 몇 분 기다린다
필요하다면 clean boot
warm-up을 넣는다
A / B를 교대로 돌린다
횟수를 확보한다
중앙값·최소·최대·p95를 남긴다
raw data를 저장한다
차가 작다면 ETW / WPR를 취한다

기록해 두면 나중에 도움이 되는 항목

벤치의 CSV나 JSON에는 적어도 다음을 남겨 두면 강합니다.

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

가능하다면 또한 다음도 있으면 편리합니다.

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

벤치는 측정하는 것보다 나중에 해석할 수 있는 것이 더 중요하기도 합니다.

평균뿐만 아니라 중앙값과 분포를 본다

평균은 편리하지만 Windows 벤치에서는 쉽게 망가집니다.
1회만 Defender가 들어왔다, 통지가 나왔다, 다른 프로세스가 SSD를 두드렸다는 것만으로 평균이 가져가집니다.

추천은 다음입니다.

중앙값: 우선 이것을 본다
p95 / p99: tail이 악화되지 않았는지를 본다
min / max: 벗어난 방식을 본다
상자 수염 그림이나 산점도: 차가 작을 때 도움이 된다

차가 났을 때의 읽는 법

결과의 해석은 조합으로 보면 이해하기 쉽습니다.

wall-clock만 빠름

I/O, 대기 시간, 캐시, 스케줄링의 개선일지도 모릅니다.

CPU time도 cycle도 내려가 있다

구현 그 자체가 가벼워지고 있을 가능성이 높습니다.

1회째만 느림 / 빠름

cold / warm의 차입니다. 기동·초기화·캐시 생성·JIT를 의심합니다.

회를 거듭할수록 느려진다

열, 스로틀링, 메모리 압박, 백그라운드 활동을 의심합니다.

ETW / WPR로 「왜 빠른가」까지 판다

차가 작거나 이유를 읽을 수 없을 때는 Windows의 ETW(Event Tracing for Windows) 계 도구로 진행하는 것이 왕도입니다.

Microsoft의 Windows Performance Recorder(WPR)는 ETW 기반의 기록 도구이며 Windows ADK에 포함되어 있습니다.
CPU, I/O, context switch, 페이지 폴트 등을 한꺼번에 취할 수 있습니다.

최소한이라면 이런 느낌입니다.

wpr -start CPU -filemode

REM 여기서 벤치를 실행한다

wpr -stop trace.etl

이 단계까지 오면,
「B 쪽이 3% 빠름」이 아니라,
「B는 lock 대기가 줄어 ready time이 내려가 있다」
「A는 file open이 늘어 cold start가 느림」
처럼 이유를 붙여 이야기할 수 있게 됩니다.

정리

Windows에서 버전 차이의 프로그램을 비교할 때 정말로 효과가 있는 것은 화려한 이면 기법이 아닙니다.
중요한 것은 다음과 같은 수수하지만 재현성에 효과가 있는 작법입니다.

AC / Power mode / power plan을 고정해 기록한다
cold와 warm을 나눈다
A / B를 교대로 돌린다
중앙값과 분포를 본다
필요하다면 clean boot
차가 작다면 ETW / WPR로 이유까지 판다

그리고 가장 중요한 것은 무엇을 고정하고 무엇을 고정하지 않았는지를 결과와 함께 쓰는 것입니다.
벤치는 속도의 비교임과 동시에 실험 조건의 기록이기도 합니다.

조건이 쓰여 있지 않은 고속화 보고는 가끔 맞히는 점술 정도로는 재미있지만, 재현성이라는 의미에서는 꽤 의지할 수 없습니다.
반대로 조건이 제대로 쓰여 있으면 차가 작더라도 그 결과에는 제대로 가치가 있습니다.

참고 자료

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

Windows 앱 개발

상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.

서비스 보기 문의하기

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

프로필 보기 문의하기

공개 링크

GitHub LinkedIn X COM_BLAS COM_BigDecimal