.네트 윈도우즈 폼즈와 wpf의 윈도우즈 메시지 처리 성능 비교

wpf가 윈도우즈 폼즈보다 좋다. 나중에 만든 거니 당연하다. 더 예쁘고 더 빠르다. 문제는 윈도우즈 메시지 처리 성능이다.

윈도우즈 메시지 시스템은 윈도우즈 컨트롤들의 핸들을 전제로 한다. 하지만 wpf는 핸들로 컨트롤들을 제어하지 않는다. 이런 차이 때문에 wpf에서 윈도우즈 메시지를 처리하려면 변칙을 써야 한다. 더 느릴 거라 예상하는 게 당연하다.

같은 기능의 애플리캐이션들을 만들어 하나의 컴퓨터에서 동시에 실행하여 비교를 해 봤다. 예상과 달리 wpf가 더 빨랐다.

4,700개를 넘는 코스피와 코스닥 모든 종목들에 대한 체결, 호가, 프로그램 매매, 거래원 대이터를 advise하여 스트림으로 받았다. 8시 전에 실행했고 첫 대이터를 받은 때부터 1분 간격으로 타이머를 작동하여 수신한 패키트의 수를 출력했다. 타이머들은 100 밀리세컨드로 작동했고 모두 로컬 시스템의 시간을 로그했다.

패키트를 수신한 뒤 Count++만 실행했다. 그 뒤의 처리는 윈도우즈 폼즈나 wpf나 같기 때문이다. 폭주하는 윈도우즈 메시지들을 순수하게 어느 게 밀리지 않고 처리하는지만 측정했다. 물론 dll api였다. com api로는 저렇게 많이 어드바이즈하면 거의 멈춘다.

첫 값들은 08:01:00에 윈도우즈 폼즈 122,786 wpf 122,579로 전자가 더 많이 시작했다.

08:05:00에 두 애플리캐이션 모두 489,154로 같은 값을 출력했다.

그 뒤로 08:09:00까지 엎치락뒤치락하다 08:10:00부터 wpf가 계속 더 큰 값을 보였다. 이때 값들은 각각 834,187과 834,281로 94 차이였다. 이 차이는 측정을 마친 09:26:01에 각각 11,870,887과 11,876,789로 5,902까지 벌어졌다.

wpf가 09:25:01에 11,636,749이었으니 1분 동안 240,040번 수신을 했고 이를 60으로 나누면 4,000.66이니 1초에 평균 4천 개의 패키트를 받은 거다.

모두 0초에 시작했지만 윈도우즈 폼즈는 09:03:01에 초가 늘었고 wpf는 09:02:01에 늘었다. 이는 전자의 틱이 더 빨랐다는 뜻이다. wpf가 더 늦게까지 받았으니 더 많이 받은 건 당연하다. 하지만 그 차이가 1초 동안 받은 거보다 컸다는 데에 의미가 있다.

wpf의 윈도우즈 메시지 핸들링이 윈도우즈 폼즈의 그것보다 얼마나 더 많았냐 하는 건 중요한 게 아니다. 더 느리지 않았다는 게 핵심이다.

결과를 알리지 않고 코드만으로 어느 애플리캐이션의 카운트가 더 많을 거 같냐고 코파일러트, 퍼플렉서티, 제미나이, 딥시크, 클로드, 채트gpt에 물었다. 퍼플렉서티만 맞췄고 다른 것들은 모두 윈도우즈 폼즈가 더 많은 수신을 할 거라 했다.