Производительность приложений Qt по сравнению с WinAPI/MFC/WTL/

Я рассматриваю возможность написания нового приложения для Windows GUI, где одним из требований является то, что приложение должно быть очень отзывчивым, быстрым для загрузки и иметь легкий объем памяти.

Я использовал WTL для предыдущих приложений, которые я создал с этим типом требований, но поскольку я все время использую .NET в свое время, работа WTL становится все более и более болезненной, чтобы вернуться. Мне неинтересно использовать .NET для этого приложения, так как я по-прежнему считаю, что производительность больших .NET-интерфейсов отсутствует, но я заинтересован в использовании лучшей С++-рамки для UI-подобных Qt.

Я хочу быть уверенным, что прежде чем начать, я не буду сожалеть об этом на фронте производительности.

Итак: Qt быстр?

Я попытаюсь сформулировать вопрос на примерах того, что я хотел бы приблизиться к совпадению: My current WTL app Блокнот программиста. Текущая версия, над которой я работаю, весит около 4 МБ кода для 32-разрядной версии с выпущенной версией с одним переводом языка. На современном быстром ПК загрузка занимает 1-3 секунды, что важно, так как люди часто запускают его, чтобы избежать IDE и т.д. Объем памяти обычно составляет 12-20 мб на 64-битной Win7, как только вы редактируете в то время как. Вы можете запустить приложение без остановок, оставьте его сведенным к минимуму, что бы то ни было, и он всегда мгновенно переключается на него, когда вы переключаетесь на него.

Для аргумента позвольте сказать, что я хочу портировать мое приложение WTL в Qt для потенциальной будущей кросс-платформенной поддержки и/или гораздо более простой интерфейс пользовательского интерфейса. Я хочу приблизиться, если не соответствовать этому уровню производительности с Qt.

Ответ 1

Going native API - самый эффективный выбор по определению - ничего, кроме этого, является оберткой вокруг собственного API.

Что именно вы ожидаете быть узким местом производительности? Любые строгие номера? Честно говоря, расплывчатый, очень отзывчивый, быстрый для загрузки и светлый объем памяти "звучит как требование, собирающее ошибку для меня. Производительность часто недооценивается.

К моменту:

Механизм щелевых сигналов Qt работает очень быстро. Он статически вводит и переводит с помощью MOC на довольно простые вызовы меток слотов.

Qt предлагает хорошую поддержку многопоточности, так что вы можете иметь гибкий графический интерфейс в одном потоке и все остальное в других потоках без особых проблем. Это может сработать.

Ответ 2

Просто задирайтесь своим опытом, если вы все еще не решили его, или кто-то еще ищет больше опыта. Недавно я разработал довольно тяжелый (обычный QGraphicsView, OpenGL QGraphicsView, доступ к базе данных QtSQL,...) с Qt 4.7 И я также уверен в производительности. Конечно, это включает в себя начальную производительность, мне нравятся мои приложения, которые появляются почти мгновенно, поэтому я трачу на это немного времени.

Скорость: Фантастично, у меня нет жалоб. Мое тяжелое приложение, которое должно создавать не менее 100 виджетов при запуске в одиночку (предоставлено, многие из них - QLabels) запускается за долю секунды (я не замечаю задержки между двойным щелчком и появлением окна).

Память. Это плохая часть, Qt со многими подсистемами, в моем опыте, использует заметный объем памяти. И снова это означает, что использование многих подсистем, QtXML, QtOpenGL, QtSQL, QtSVG, вы называете это, я использую его. Моему текущему приложению при запуске удается использовать около 50 МБ, но он начинает молниеносно и быстро реагирует.

Простота программирования /API : Qt - это абсолютная радость от использования от своих контейнеров до классов виджета до его модулей. Все это время упрощает управление памятью (QObject) и обеспечивает высокую производительность. Я всегда писал чистый win32 до этого, и я никогда не вернусь. Например, с классами QtConcurrent мне удалось изменить вызов метода от myMethod(arguments) до QtConcurrent::run(this, MyClass::myMethod, arguments), а с одной единственной строкой был использован поточный метод обработки без GUI. С помощью QFuture и QFutureWatcher я мог отслеживать, когда поток закончился (либо с помощью сигналов, либо только с проверкой метода). Какая простота использования! Очень элегантный дизайн вокруг.

Итак, в ретроспективе: очень хорошая производительность (включая запуск приложения), довольно высокое использование памяти, если используется много подмодулей, фантастический API и возможности, кросс-платформенный

Ответ 3

Блокнот программиста - текстовый редактор, который использует Scintilla в качестве основного компонента редактирования текста и WTL в качестве библиотеки пользовательского интерфейса.

JuffEd - текстовый редактор, который использует QScintilla в качестве основного компонента редактирования текста и Qt в качестве библиотеки пользовательского интерфейса.

Я установил последние версии Блокнот программистов и JuffEd и изучил объем памяти обоих редакторов, используя Process Explorer.

Пустой файл:
- juffed.exe Частные байты: 4,532K Виртуальный размер: 56,288K
- pn.exe Частные байты: 6,316K Виртуальный размер: 57,268K

"wtl\Include\atlctrls.h" (264K, ~ 10.000 строк, прокручивается от начала до конца несколько раз):
- juffed.exe Частные байты: 7,964K Виртуальный размер: 62,640K
- pn.exe Частные байты: 7,480K Виртуальный размер: 63,180K

после выбора всех (Ctrl-A), вырезания (Ctrl-X) и вставки (Ctrl-V)
- juffed.exe Частные байты: 8,488K Виртуальный размер: 66,700K
- pn.exe Частные байты: 8,580K Виртуальный размер: 63,712K

Обратите внимание, что при прокрутке (Pg Down/Pg Up нажато) JuffEd, казалось, потреблял больше процессора, чем блокнот программиста.

Комбинированные размеры exe и dll:
- 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

Вышеприведенное сравнение несправедливо, потому что JuffEd не был скомпилирован с Visual Studio 2005, который должен генерировать меньшие двоичные файлы.

Ответ 4

Мы уже много лет используем Qt, разрабатывая приложение пользовательского интерфейса хорошего размера с различными элементами пользовательского интерфейса, включая 3D-окно. Всякий раз, когда мы сталкиваемся с серьезным замедлением производительности приложений, это обычно наша ошибка (мы делаем много доступа к базе данных), а не пользовательский интерфейс.

За последние годы они много работали, чтобы ускорить рисование (именно там большая часть времени тратится). В общем, если вы действительно не реализуете своего рода редактор, обычно в пользовательском интерфейсе не хватает времени на выполнение кода. Он в основном ждет ввода от пользователя.

Ответ 5

Общая производительность программы, конечно же, будет зависеть от вас, но я не думаю, что вам нужно беспокоиться о пользовательском интерфейсе. Благодаря графической сцене и поддержке OpenGL вы также можете быстро создавать 2D/3D-графику.

И последнее, но не менее важное: пример из моего собственного опыта:

Использование Qt на Linux/Embedded XP с 128 МБ RAM. Windows использует MFC, Linux использует Qt. Пользовательский графический пользовательский интерфейс с большим количеством рисунков и обычный графический интерфейс администратора с элементами управления/виджетами. С точки зрения пользователя Qt работает так же быстро, как MFC. Примечание: это полная программа, которая не может быть сведена к минимуму.

Отредактировано после добавления дополнительной информации: вы можете ожидать большего размера исполняемого файла (особенно с Qt MinGW) и большего использования памяти. В вашем случае попробуйте сыграть с одной из IDE (например, Qt Creator) или текстовые редакторы, написанные в Qt, и посмотреть, что вы думаете.

Ответ 6

Qt - очень хорошая структура, но есть штраф за производительность. Это в основном связано с живописью. Qt использует собственный рендер для рисования всего - текст, прямоугольники, вы называете его... В базовую систему окон каждое приложение Qt выглядит как одно окно с большим растровым изображением внутри. Нет вложенных окон, ничего. Это полезно для рендеринга без мерцания и максимального контроля над картиной, но это связано с ценой полностью отказаться от любой возможности для аппаратного ускорения. Аппаратное ускорение все еще заметно в настоящее время, например. при заполнении больших прямоугольников одним цветом, как это часто бывает в системах оконного оформления.

Тем не менее, Qt "достаточно быстро" почти во всех случаях.

В основном я наблюдаю медленность при работе на Macbook, чей вентилятор процессора очень чувствителен и оживет после нескольких секунд умеренной активности процессора. Использование мыши для прокрутки в приложении Qt загружает CPU намного больше, чем прокрутка в родном приложении. То же самое касается изменения размеров окон.

Как я уже сказал, Qt достаточно быстр, но если для вас важна повышенная разрядка батареи, или если вы заботитесь о очень плавном изменении размера окна, то у вас нет большого выбора, кроме того, что вы работаете на родном языке.

Поскольку вы, похоже, считаете, что 3-секундный запуск приложения "быстрый", похоже, что вы вообще не заботитесь о производительности Qt. Я бы подумал о 3-секундном запуске собаки-медленно, но мнения об этом меняются естественным образом.

Ответ 7

Я лично выбрал Qt, поскольку я никогда не видел ни одного удара по производительности для его использования. Тем не менее, вы можете немного приблизиться к родным с wxWidgets и все еще иметь кросс-платформенное приложение. Вы никогда не будете такими быстрыми, как прямые Win32 или MFC (и семья), но вы получите многоплатформенную аудиторию. Таким образом, вопрос для вас - стоит ли компромисс?

Ответ 8

Мой опыт в основном связан с MFC, а в последнее время с С#. MFC довольно близок к голым металлам, поэтому, если вы не определяете тонну структуры данных, она должна быть довольно быстрой.

Для рисования графики мне всегда полезно отображать растровое изображение памяти, а затем использовать это на экране. Он выглядит быстрее, и он может быть даже быстрее, потому что он не беспокоится об отсечении.

Обычно возникает проблема с производительностью, несмотря на то, что я пытаюсь ее избежать. Я использую очень простой способ найти эти проблемы: просто подождите, пока он будет субъективно медленным, приостановите его и проверьте стек вызовов. Я делаю это несколько раз - 10 обычно более чем достаточно. Это плохой профайлер, но работает хорошо, без суеты, не беспокойтесь. Проблема всегда то, о чем никто не мог догадаться, и обычно ее легко исправить. Вот почему он работает.

Если есть диалоги любой сложности, я использую свою собственную технику Динамические диалоги, потому что я испорчен. Они не для слабонервных, но очень гибкие и прекрасно работают.

Ответ 9

Я однажды сделал приложение, чтобы определить "грубость" числа (будь то простой или составной).

Сначала я попытался использовать графический интерфейс Qt, и потребовалось 5 часов, чтобы вернуть ответ на 1,299,827 на компьютер с 8 ГБ ОЗУ и AMD 1090T @4GHz, в котором нет других процессов переднего плана в Linux.

Моя вторая попытка использовала QProcess консольного приложения, которое использовало тот же самый код. На ноутбуке с 1,3 ГБ оперативной памяти и процессором 1,4 ГГц ответ пришел без заметной задержки.

Я не буду отрицать, что это намного проще, чем GTK + или Win32, и он отлично справляется с задачами, но отвлекает интенсивную обработку от GUI, если вы его используете.