Wydajność aplikacji Qt vs. WinAPI/MFC/WTL/

Question

Rozważam napisanie nowej aplikacji GUI dla systemu Windows, gdzie jednym z wymogów jest to, że aplikacja musi być bardzo responsywna, szybka do załadowania i ma mały ślad pamięci.

Użyłem WTL dla poprzednich aplikacji, które stworzyłem z tego rodzaju wymogiem, ale jak używam .NET cały czas w mojej codziennej pracy WTL staje się coraz bardziej bolesne, aby wrócić. Nie jestem zainteresowany korzystaniem z .NET dla tej aplikacji, ponieważ wciąż brakuje mi wydajności większych .NETowych interfejsów użytkownika, ale jestem zainteresowany wykorzystaniem lepszej struktury C++ dla interfejsu użytkownika - jak Qt.

Przed rozpoczęciem staram się mieć pewność, że nie będę tego żałował na froncie wydajności.

A więc: czy Qt jest szybkie?

Postaram się zakwalifikować pytanie za pomocą przykładów tego, co chciałbym przybliżyć do dopasowania: Moja aktualna aplikacja WTL to Programmer's Notepad. Obecna wersja, nad którą pracuję, waży około 4 MB kodu dla 32-bitowej, wydanej kompilowanej wersji z pojedynczym tłumaczeniem językowym. Na nowoczesnym, szybkim komputerze ładowanie trwa 1-3 sekund, co jest ważne, ponieważ ludzie często go uruchamiają, aby uniknąć IDE itp. W 64-bitowym Win7, gdy edytujesz podczas. Możesz uruchamiać aplikację non-stop, pozostawić ją zminimalizowaną, cokolwiek i zawsze przeskakuje na nią natychmiast po przełączeniu się na nią.

Dla dobra argumentu powiedzmy, że chcę przenieść moją aplikację WTL do Qt na potencjalną, przyszłościową obsługę wielu platform i/lub znacznie łatwiejszy interfejs użytkownika. Chcę zbliżyć się, jeśli nie pasować do tego poziomu wydajności z Qt.

Answer 1

Przechodzenie z natywnego interfejsu API jest najbardziej wydajnym wyborem z definicji - wszystko inne, niż otok w otoczeniu natywnego interfejsu API.

Czego można się spodziewać po wąskim gardle wydajności? Jakieś ścisłe liczby? Szczerze mówiąc, niejasne, bardzo czułe, szybkie ładowanie i mający niewielki ślad pamięci "brzmi jak wymóg gromadzenia mi błędu. Wydajność jest często zbyt duża.

Do punktu:

Qt Mechanizm sygnał-slot jest naprawdę szybki. Jest statycznie wpisany i tłumaczy się za pomocą MOC na całkiem proste wywołania w automatach.

Qt oferuje ładną obsługę wielowątkowości, dzięki czemu możesz mieć responsywny GUI w jednym wątku i cokolwiek innego w innych wątkach bez większego problemu. To może zadziałać.

Answer 2

Ogólna wydajność programu oczywiście zależy od Ciebie, ale nie sądzę, że musisz martwić się interfejsem użytkownika. Dzięki graficznej scenie i obsłudze OpenGL możesz robić szybką grafikę 2D/3D.

Last but not least, przykład z własnego doświadczenia:

• Korzystanie z Qt na Linux/wbudowanego maszynie XP z 128 MB pamięci RAM. Windows używa MFC, Linux używa Qt. Niestandardowy GUI użytkownika z mnóstwem obrazków i zwykłym GUI administratora z kontrolkami/widżetami. Z punktu widzenia użytkownika Qt działa tak szybko, jak MFC. Uwaga: był to program pełnoekranowy, którego nie można zminimalizować.

edytować po dodaniu więcej informacji: można oczekiwać większy rozmiar pliku wykonywalnego (szczególnie z Qt MinGW), a zużycie pamięci. W twoim przypadku spróbuj grać z jednym z IDE (np.Qt Creator) lub text editors napisane w Qt i zobaczyć, co myślisz.

Answer 3

Używamy Qt od wielu lat, tworząc aplikację UI o dobrej wielkości z różnymi elementami w interfejsie, w tym o oknie 3D. Za każdym razem, gdy osiągamy znaczne spowolnienie działania aplikacji, zwykle jest to nasza wina (robimy dużo dostępu do baz danych), a nie interfejsy użytkownika.

W ostatnich latach wykonali wiele pracy, aby przyspieszyć rysowanie (tutaj spędza się większość czasu). Ogólnie rzecz biorąc, chyba że naprawdę zaimplementujesz rodzaj edytora, zwykle nie ma zbyt wiele czasu na wykonywanie kodu wewnątrz interfejsu użytkownika. Przeważnie czeka na dane od użytkownika.

Answer 4

Osobiście wybrałbym Qt, ponieważ nigdy nie widziałem żadnego uderzenia wydajnościowego z jego używania. Powiedziawszy, możesz zbliżyć się do native z wxWidgets i nadal mieć aplikację na wiele platform. Nigdy nie będziesz dość tak szybki jak prosty Win32 lub MFC (i rodzina), ale zyskasz wieloplatformową publiczność. Pytanie dla ciebie brzmi: czy to jest warte odrobiny kompromisu?

Answer 5

Moje doświadczenie jest głównie z MFC, a ostatnio z C#. MFC jest dość zbliżone do gołego metalu, więc jeśli nie zdefiniujesz mnóstwa struktury danych, powinno to być dość szybkie.

Do malowania grafiki zawsze przydaje się renderowanie do bitmapy pamięci, a następnie blt do tego na ekranie. Wygląda na to, że jest szybszy i może być nawet szybszy, ponieważ nie martwi się przycinaniem.

Zwykle pojawia się jakiś problem z wydajnością, mimo że staram się go ominąć. Używam bardzo prostego sposobu na znalezienie tych problemów: po prostu poczekaj, aż będą subiektywnie wolne, zatrzymaj je i sprawdź stos wywołań. Robię to wiele razy - 10 to zwykle więcej niż wystarczające. To profiler biedaka, ale działa dobrze, bez problemów, bez kłopotów. Problemem jest zawsze coś, czego nikt nie mógł odgadnąć i zazwyczaj łatwo go naprawić. This is why it works.

Jeśli są okna dialogowe o dowolnej złożoności, używam własnej techniki, Dynamic Dialogs, ponieważ jestem rozpieszczany. Nie są przeznaczone dla osób o słabych nerwach, ale są bardzo elastyczne i ładnie działają.

Answer 6

Programmer's Notepad to edytor tekstu, który używa Scintilla jako podstawowego komponentu edytującego tekst i WTL jako biblioteki interfejsu użytkownika.

JuffEd to edytor tekstu, który używa QScintilla jako komponentu edytującego tekst i Qt jako biblioteki interfejsu użytkownika.

Zainstalowałem najnowsze wersje Notatnika programisty i JuffEd i przestudiowałem ślad pamięci obu edytorów przy użyciu Process Explorer.

Pusty plik:
- juffed.exe Bajty prywatne: 4,532K Wirtualna Wielkość: 56,288K
- pn.exe Bajty prywatne: 6,316K Wirtualna Wielkość: 57,268K

„WTL \ Include \ atlctrls. h "(264K, ~ 10.000 linii, przewijanych od początku do końca kilka razy):
- juffed.exe Bajty prywatne: 7,964K Wirtualny rozmiar: 62,640K
- pn.exe Prywatne bajty: 7,480K Wirtualny rozmiar: 63.180 K

po wybraniu wszystkich (Ctrl-A), wycięciu (Ctrl-X) i wklejeniu (Ctrl-V)
- juffed.exe Bajty prywatne: 8,488K Wielkość wirtualna: 66,700 K
- pn.exe Prywatne bajty: 8 580K Wirtualny rozmiar: 63,712 K

Podczas przewijania (naciśnięcie klawisza Pg w dół/w górę) JuffEd wydaje się jeść więcej procesora niż Notatnik programisty.

Combined exe i dll rozmiary:
- juffed.exe QtXml4.dll QtGui4.dll QtCore4.dll qscintilla2.dll mingwm10.dll libjuff.dll 14MB
- pn.exe SciLexer.dll msvcr80.dll msvcp80.dll msvcm80.dll libexpat.dll ctagsnavigator.dll pnse.dll 4.77 Mb

Powyższe porównanie nie jest sprawiedliwe, ponieważ JuffEd nie został skompilowany z Visual Studio 2005, który powinien generować mniejsze pliki binarne.

Answer 7

Qt to bardzo ładne ramy, ale jest kara za wydajność. Dotyczy to głównie malowania. Qt używa własnego renderera do malowania wszystkiego - tekstu, prostokątów, jak to nazywasz ... Do podstawowego systemu okiennego każda aplikacja Qt wygląda jak pojedyncze okno z dużą bitmapą w środku. Bez zagnieżdżonych okien, bez niczego. Jest to dobre dla renderowania bez migotania i maksymalnej kontroli nad obrazem, ale dzieje się tak za cenę całkowitego zniesienia jakiejkolwiek możliwości przyspieszenia sprzętowego. Akceleracja sprzętowa jest nadal zauważalna w dzisiejszych czasach, np. przy wypełnianiu dużych prostokątów jednym kolorem, jak to często bywa w systemach okiennych.

To powiedziawszy, Qt jest "wystarczająco szybki" w prawie wszystkich przypadkach.

Najczęściej zauważam powolność podczas uruchamiania na MacBooku, którego wentylator procesora jest bardzo czuły i ożyje po zaledwie kilku sekundach umiarkowanej aktywności procesora. Używanie myszy do przewijania w aplikacji Qt ładuje procesor znacznie bardziej niż przewijanie w natywnej aplikacji. To samo dotyczy zmiany rozmiaru okien.

Jak już powiedziałem, Qt jest wystarczająco szybki, ale jeśli zwiększone rozładowywanie baterii ma dla ciebie znaczenie, lub jeśli zależy ci na bardzo płynnym dopasowywaniu okna, to nie masz wielkiego wyboru, poza tym, że jesteś tubylcem.

Ponieważ wydaje się, że rozpoczęcie 3 sekundowego uruchamiania aplikacji jest "szybkie", nie brzmi to tak, jakby w ogóle dbać o wydajność Qt. Rozważałbym 3-sekundowy startowy pies, ale opinie na ten temat różnią się w sposób naturalny.

Answer 8

Po prostu dzwonię z moim doświadczeniem, na wypadek, gdybyś jeszcze go nie rozwiązał lub ktoś inny szuka więcej doświadczenia. Niedawno opracowałem dość ciężką (regularną aplikację QGraphicsView, OpenGL QGraphicsView, dostęp do baz danych QtSQL, ...) z Qt 4.7, a także jestem zwolennikiem wydajności. Obejmuje to oczywiście uruchomienie, lubię, gdy moje aplikacje pojawiają się niemal natychmiast, więc poświęcam na to sporo czasu.

Prędkość: Fantastycznie, nie mam żadnych skarg. Moja ciężka aplikacja, która musi utworzyć co najmniej 100 widżetów podczas samego uruchamiania (przyznane, wiele z nich to QLabels) uruchamia się w ułamku sekundy (nie zauważam żadnego opóźnienia między dwukrotnym klikaniem a wyświetlaniem okna).

Pamięć: To jest zła część, Qt z wieloma podsystemami na moim doświadczeniu używa zauważalnej ilości pamięci. Z drugiej strony to się liczy dla wielu zastosowań podsystemów, QtXML, QtOpenGL, QtSQL, QtSVG, jak go nazwiesz, ja go używam. Mój obecny aplikacji przy starcie uda się wykorzystać około 50 MB, ale uruchamia się błyskawicznie i reaguje szybko, jak dobrze

Łatwość programowania/API: Qt jest absolutną radość korzystania z jego pojemników do swoich klas widżet jego moduły. Wszystko to sprawia, że ​​zarządzanie pamięcią jest łatwe (QObject) i zachowuje super wydajność.Zawsze pisałem czystą win32 przed tym i ja nigdy nie powrócę do. Na przykład przy klasach QtConcurrent mogłem zmienić wywołanie metody z myMethod(arguments) na QtConcurrent::run(this, MyClass::myMethod, arguments) iw jednym wierszu została naniesiona ciężka metoda przetwarzania bez GUI. Dzięki QFuture i QFutureWatcher mogłem monitorować, kiedy wątek się skończył (albo z sygnałami, albo po prostu sprawdzeniem metody). Jaką łatwość użycia! Bardzo elegancki design dookoła.

Więc z perspektywy czasu: bardzo dobre wyniki (w tym aplikacji starcie), dość wysokie zużycie pamięci, jeśli stosuje się wiele Submoduły, fantastycznej API i możliwości, cross-platform

Answer 9

kiedyś złożył aplikację do określenia " prymat "liczby (bez względu na to, czy była pierwotna czy złożona).

Po raz pierwszy podjąłem Qt GUI, a otrzymanie odpowiedzi na 1 299,827 zajęło 5 godzin na komputerze z 8 GB pamięci RAM i AMD 1090T @ 4GHz bez żadnych innych procesów na pierwszym planie pod Linuksem.

Moja druga próba wykorzystała QProcess aplikacji konsolowej, która używała tego samego kodu. Na laptopie z 1,3 GB pamięci RAM i procesorem 1,4 GHz odpowiedź pojawiła się bez zauważalnego opóźnienia.

Nie będę jednak zaprzeczył, że jest to znacznie łatwiejsze niż GTK + lub Win32, i radzi sobie całkiem nieźle, ale osobno intensywnie przetwarza CAŁKOWICIE z GUI, jeśli go używasz.