해결된 질문
작성
·
60
답변 3
0
쉽게 생각해서 Event handler 시스템을 Lookup table로 만든다고 생각하시면 되겠습니다. 항상 그런 것은 아니지만 다수의 switch-case문은 Lookup table 구조로 변경 할 수 있습니다. 이렇게 하면 높은 성능향상을 기대 할 수 있고요. 더 자세한 정보는 Lookup table에 대해 찾아보시기 바랍니다. 참고하시기 바랍니다. 😄
(참, 독하게 시작하는 C, 독하게 시작하는 Java 강의에 Lookup table에 관한 내용이 들어 있습니다.)
메시지 큐는 선형 자료구조이며 큐를 중심으로 병목 현상이 나는 것은 구조적인 부분입니다. 개선의 여지도 별로 없고요. 큐에 데이터가 쌓이는 것은 메시지 처리 지연 때문에 발생할 수 있습니다. 그 문제와 질문의 내용은 별개로 봐야 하겠습니다. 다시 말씀드리지만 Lookup table에 대해 알아보시기 바랍니다.
병목 현상이 나는 것은 구조적인 부분이고 개선의 여지도 없는 건데, 강의에서는 병목 현상을 언급하고 MFC로 개선할 수 있다고 말씀하셔서 오해의 여지가 있다고 생각합니다.
switch case문이 컴파일 타임에 최적화가 일어나면 메시지 맵보다 더 성능적으로 이점을 얻을 수도 있을 것 같긴한데 여기에 대해서는 어떻게 생각하시는지 궁금합니다.
switch-case는 컴파일러 최적화가 불가능한 구조입니다. case가 늘어날 수록 마지막에 기술한 case는 여러 번 비교 연산을 수행한 다음에 확인되기 때문입니다. 다시 말씀드리지만 Lookup table 구조에 대해서 알아 보시기 바랍니다. 😄
0
AI 답변을 원하지 않습니다.
강사님께서 WinAPI 병목 현상을 개선해서 나오는 게 MFC라고 말씀하셨는데요. 메시지맵을 언급하면서요. 어떻게 병목 현상을 개선했는지에 대해서 설명이 없습니다. 설명좀 부탁드립니다.
0
안녕하세요, 인프런 AI 인턴입니다. 이성원님.
메시지 루프에서 메시지 처리 성능에 대한 문의를 주셨군요. WinAPI와 MFC 간의 메시지 처리 방법에 대해 조금 더 자세히 설명드리겠습니다.
WinAPI에서는 메시지를 처리할 때 주로 switch case
문을 사용합니다. 이 방법은 코드가 간단하지만, 많은 메시지를 처리해야 할 경우 코드가 복잡해질 수 있습니다. 이 과정에서 병목 현상이 발생할 가능성도 존재합니다. 그러나 성능상의 차이보다는 코드의 복잡도와 유지보수 측면에서의 문제라고 볼 수 있습니다.
MFC에서는 메시지 맵
을 통해 메시지를 처리합니다. 메시지 맵은 각 메시지를 해당 메시지를 처리하는 함수와 연결해주는 역할을 하며, 코드가 깔끔하게 작성될 수 있고, 확장성이나 유지보수 측면에서 유리합니다. 하지만, MFC의 메시지 맵도 결국은 내부적으로는 비슷한 방법으로 메시지를 분배하기 때문에, 성능 차이가 매우 크다고 보기는 어렵습니다.
즉, 성능보다는 코드 구조와 가독성, 유지보수성 측면에서의 차이가 더 크다고 볼 수 있습니다. MFC를 사용하면 메시지 처리 코드가 좀 더 간결하고 명확해질 수 있습니다.
다음 자료들이 도움이 되실 수 있습니다:
- MFC의 메시지 맵 이해하기: MFC 메시지 맵의 동작 방식에 대한 자세한 설명
- WinAPI와 MFC의 메시지 처리 비교: 두 기술에서의 차이점 설명
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
아무리 그래도 병목 현상을 개선할 수가 있나요?
병목 현상이란 게 메시지 처리하는 함수에 따라서 처리 시간이 각기 다를테고.. 좀 느린 것도 있을텐데요. 그래서 메시지가 메시지 큐에 많이 쌓여서 병목 현상이 발생하는 거잖아요?
이걸 메시지 맵으로 변경한다고 병목 현상을 해결할 수 있다는 게 잘 이해가 안 가네요.