[WinAPI] - GetMessage() vs. PeekMessage()
Ostatnio zmodyfikowano 2015-07-13 20:38
carlosmay Temat założony przez niniejszego użytkownika |
[WinAPI] - GetMessage() vs. PeekMessage() » 2015-07-12 00:41:16 GetMessage() czeka i blokuje wykonywanie programu, gdy w kolejce nie ma komunikatów. PeekMessage() pozwala wykonywać się programowi mimo braku komunikatów w kolejce. Pytanie: Pytam o zasadność użycia GetMessage(), gdy jest PeekMessage(). Czy PeekMessage() mocno zmniejsza wydajność, gdy tak działa w pętli czekając aż pojawi się komunikat? |
|
pekfos |
» 2015-07-12 14:46:58 To dwie różne funkcje do stosowania w różnych przypadkach. Zbliżone zachowanie to trochę mało do takiego porównania "co jest lepsze". PeekMessage() pozwala wykonywać się programowi mimo braku komunikatów w kolejce. |
Podobnie jak GetMessage(). Czy PeekMessage() mocno zmniejsza wydajność, gdy tak działa w pętli czekając aż pojawi się komunikat? |
Co to jest wydajność? Szybkość wykonania zadania..? Pętla, która robi nic na pewno jest w nicnierobieniu wolniejsza, niż brak kodu w ogóle. Jaki jest sens, by komputer miał tracić czas na kręcenie się bez sensu w takiej pętli zdarzeń, gdy zdarzeń nie ma? Aplikacje użytkowe są zupełnie innej architektury niż np gry, gdzie jakaś pętla musi się kręcić niezależnie od zdarzeń, i nie wymagają takiego podejścia. Mają reagować na polecenia, a w międzyczasie robić jak najmniej. Taka jest idea blokujących funkcji - nie kręcić się bez sensu w sprawdzaniu, tylko zablokować się do jakiegoś momentu. Są do tego dobre mechanizmy i rezygnowanie z nich tylko dlatego, że jest 'fajniejsza, ogólniejsza funkcja' mija się z celem. |
|
carlosmay Temat założony przez niniejszego użytkownika |
» 2015-07-12 15:36:09 OK. Właśnie o to mi chodziło. Dzięki. zamykam. |
|
Elaine |
» 2015-07-13 16:30:02 Aplikacje użytkowe są zupełnie innej architektury niż np gry, gdzie jakaś pętla musi się kręcić niezależnie od zdarzeń, i nie wymagają takiego podejścia. Mają reagować na polecenia, a w międzyczasie robić jak najmniej. |
Co nie znaczy, że nie mogą używać PeekMessage. Czasem nawet muszą, bo zachodzi potrzeba zrobienia czegoś po obsłużeniu komunikatów, ale przed rozpoczęciem oczekiwania na następne, albo potrzeba czekania na coś w rodzaju semafora nie zapominając jednocześnie o obsłudze komunikatów. Przykład pierwszej sytuacji, wzięty z życia: for(;; ) { MSG msg; while( PeekMessageW( & msg, nullptr, 0, 0, PM_REMOVE ) != 0 ) { if( msg.message == WM_QUIT ) { return msg.wParam; } TranslateMessage( & msg ); DispatchMessageW( & msg ); } logger::writePendingBuffer(); WaitMessage(); } |
|
carlosmay Temat założony przez niniejszego użytkownika |
» 2015-07-13 20:38:03 Dzieki za wyjaśnienia. Już rozumiem. |
|
« 1 » |