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

Programmer's Notepad is an text editor which uses Scintilla as the text editing core component and WTL as UI library.

JuffEd is a text editor which uses QScintilla as the text editing core component and Qt as UI library.

I have installed the latest versions of Programmer's Notepad and JuffEd and studied the memory footprint of both editors by using Process Explorer.

Empty file:
- juffed.exe Private Bytes: 4,532K Virtual Size: 56,288K
- pn.exe Private Bytes: 6,316K Virtual Size: 57,268K

"wtl\Include\atlctrls.h" (264K, ~10.000 lines, scrolled from beginning to end a few times):
- juffed.exe Private Bytes: 7,964K Virtual Size: 62,640K
- pn.exe Private Bytes: 7,480K Virtual Size: 63,180K

after a select all (Ctrl-A), cut (Ctrl-X) and paste (Ctrl-V)
- juffed.exe Private Bytes: 8,488K Virtual Size: 66,700K
- pn.exe Private Bytes: 8,580K Virtual Size: 63,712K

Note that while scrolling (Pg Down / Pg Up pressed) JuffEd seemed to eat more CPU than Programmer's Notepad.

Combined exe and dll sizes:
- 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, который должен генерировать меньше двоичные файлы.

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

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

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

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

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

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

My experience is mostly with MFC, and more recently with C#. MFC is pretty close to the bare metal so unless you define a ton of data structure, it should be pretty quick.

For graphics painting, I always find it useful to render to a memory bitmap, and then blt that to the screen. It looks faster, and it may even be faster, because it's not worrying about clipping.

There usually is some kind of performance problem that creeps in, in spite of my trying to avoid it. I use a very simple way to find these problems: just wait until it's being subjectively slow, pause it, and examine the call stack. I do this a number of times - 10 is usually more than enough. It's a poor man's profiler but works well, no fuss, no bother. The problem is always something no one could have guessed, and usually easy to fix. This is why it works.

If there are dialogs of any complexity, I use my own technique, Dynamic Dialogs, because I'm spoiled. They are not for the faint-of-heart, but are very flexible and perform nicely.

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

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

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

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

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

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

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

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

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

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

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

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

тогда у вас не будет другого выбора, кроме как перейти на нативный.

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

тогда у вас не будет другого выбора, кроме как перейти на нативный.

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