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

Question

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

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

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

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

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

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

Answer 1

Просто поделитесь своим опытом на тот случай, если вы все еще не решили его или кто-то еще ищет дополнительный опыт. Недавно я разработал довольно тяжелое (обычное 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), и с помощью одной строки был добавлен многопоточный метод обработки без графического интерфейса пользователя. С помощью QFuture и QFutureWatcher я мог отслеживать, когда закончился поток (либо с помощью сигналов, либо только с помощью проверки метода). Какая простота использования! Очень элегантный дизайн вокруг.

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

Answer 2

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

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

К вопросу:

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

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

Answer 3

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

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

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

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

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

после выбора всех (Ctrl-A), вырезать (Ctrl-X) и вставить (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Виртуальный размер: 66,700K
- pn.exe Private Bytes: 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 МБ

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

Однажды я сделал приложение, чтобы определить «простоту» числа (простого или составного).

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

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

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

Answer 9

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

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

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

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