Qt Application Performance vs. WinAPI/MFC/WTL/

Question

Estoy considerando escribir una nueva aplicación Windows GUI, donde uno de los requisitos es que la aplicación debe ser muy receptiva, rápida de cargar y tener una memoria ligera.

He utilizado WTL para aplicaciones anteriores que he creado con este tipo de requisitos, pero como utilizo .NET todo el tiempo en mi trabajo cotidiano, WTL se está volviendo cada vez más doloroso al volver. No estoy interesado en usar .NET para esta aplicación, ya que todavía me falta el rendimiento de las IU de .NET más grandes, pero estoy interesado en utilizar un mejor marco C++ para la interfaz de usuario, como Qt.

Lo que quiero asegurarme antes de comenzar es que no voy a arrepentirme de esto en el frente de rendimiento.

So: ¿Qt es rápido?

Voy a intentar y calificar la pregunta con ejemplos de lo que me gustaría estar cerca de hacer coincidir: Mi actual aplicación WTL es Programmer's Notepad. La versión actual en la que estoy trabajando pesa aproximadamente 4 MB de código para una versión compilada de lanzamiento de 32 bits con una sola traducción de idioma. En un PC rápido moderna que toma 1-3 segundos la carga, lo cual es importante ya que la gente a menudo disparan hacia arriba para evitar IDE etc. La huella de la memoria suele ser de 12-20 mb en 64 bits Win7 una vez que haya estado editando para una mientras. Puede ejecutar la aplicación sin parar, dejarla minimizada, lo que sea y siempre salta a la atención de forma instantánea cuando se cambia a ella.

En aras de la argumentación, digamos que quiero transferir mi aplicación WTL a Qt para un futuro soporte multiplataforma y/o el marco de interfaz de usuario mucho más fácil. Quiero acercarme si no coincide este nivel de rendimiento con Qt.

Answer 1

Va API nativa es la opción mas potente por definición - nada más que eso es una envoltura alrededor de la API nativa.

¿Qué es exactamente lo que espera ser el cuello de botella? Cualquier número estricto? Honestamente, vago, muy receptivo, rápido de cargar y tiene una huella de memoria ligera, suena como un error de recopilación de requisitos para mí. El rendimiento a menudo está sobreespecificado.

Hasta el punto:

mecanismo de ranura señal de Qt es muy rápido. Está tipado estáticamente y se traduce con MOC en llamadas a métodos de ranura bastante simples.

Qt ofrece un buen soporte de subprocesos múltiples, por lo que puede tener una interfaz gráfica de usuario receptiva en un hilo y todo lo demás en otros hilos sin mucha molestia. Aquello podría funcionar.

Answer 2

Por supuesto, el rendimiento general del programa depende de usted, pero no creo que tenga que preocuparse por la interfaz de usuario. Gracias a la escena de gráficos y al soporte de OpenGL también puedes hacer gráficos 2D/3D rápidos.

Por último, pero no menos importante, un ejemplo de mi propia experiencia:

• El uso de Qt en la máquina Linux/Embedded XP con 128 MB de RAM. Windows usa MFC, Linux usa Qt. GUI de usuario personalizada con mucha pintura y una GUI de administración regular con controles/widgets. Desde el punto de vista de un usuario, Qt es tan rápido como MFC. Nota: era un programa de pantalla completa que no se podía minimizar.

Editado después de haber agregado más información: se puede esperar un mayor tamaño del ejecutable (especialmente con Qt MinGW) y más uso de la memoria. En su caso, intente jugar con uno de los IDEs (p.Qt Creator) o text editors escrito en Qt y vea lo que piensa.

Answer 3

Hemos estado usando Qt durante varios años, desarrollando una aplicación de interfaz de usuario de buen tamaño con varios elementos en la interfaz de usuario, incluida una ventana 3D. Cada vez que golpeamos una desaceleración importante en el rendimiento de la aplicación, generalmente es nuestra culpa (hacemos mucho acceso a la base de datos) y no las UI.

Han trabajado mucho en los últimos años para agilizar el dibujo (aquí es donde se pasa la mayor parte del tiempo). En general, a menos que realmente implemente un tipo de editor, generalmente no se gasta mucho tiempo en ejecutar código dentro de la interfaz de usuario. En su mayoría, espera la entrada del usuario.

Answer 4

Yo personalmente elegiría Qt ya que nunca he visto ningún golpe de rendimiento por usarlo. Dicho esto, puedes acercarte un poco más al nativo con wxWidgets y aún tener una aplicación multiplataforma. Nunca será bastante tan rápido como Win32 o MFC (y familia), pero obtendrá una audiencia multiplataforma. Entonces la pregunta para usted es, ¿vale la pena una pequeña compensación?

Answer 5

Mi experiencia es principalmente con MFC, y más recientemente con C#. MFC es muy similar al metal desnudo, por lo que a menos que defina una gran cantidad de estructura de datos, debería ser bastante rápido.

Para la pintura de gráficos, siempre me resulta útil renderizar en un mapa de bits de memoria y luego hacerlo en la pantalla. Se ve más rápido, e incluso puede ser más rápido, porque no se trata de recorte.

Por lo general, hay algún tipo de problema de rendimiento que se arrastra, a pesar de mi intento de evitarlo. Utilizo una forma muy simple de encontrar estos problemas: simplemente espere hasta que sea subjetivamente lento, deténgalo y examine la pila de llamadas. Lo hago varias veces; 10 es generalmente más que suficiente. Es un generador de perfiles de un hombre pobre, pero funciona bien, sin complicaciones, sin molestias. El problema siempre es algo que nadie podría haber adivinado, y generalmente es fácil de solucionar. This is why it works.

Si hay cuadros de diálogo de cualquier complejidad, uso mi propia técnica, Dynamic Dialogs, porque estoy en mal estado. No son para los débiles de corazón, pero son muy flexibles y funcionan bien.

Answer 6

Programmer's Notepad es un editor de texto que usa Scintilla como componente principal de edición de texto y WTL como biblioteca de UI.

JuffEd es un editor de texto que usa QScintilla como el componente principal de edición de texto y la biblioteca Qt como UI.

He instalado las últimas versiones del Bloc de notas del programador y JuffEd y he estudiado la huella de memoria de ambos editores usando Process Explorer.

archivo vacío:
- juffed.exe Bytes privados: 4,532K Tamaño virtual: 56,288K
- pn.exe Bytes privados: 6,316K Tamaño virtual: 57,268K

"wtl \ include \ atlctrls. h "(264K, ~ 10.000 líneas, desplazado de principio a fin varias veces):
- juffed.exe Bytes privados: 7,964K Tamaño virtual: 62,640K
- pn.exe Bytes privados: 7,480K Tamaño virtual: 63,180 K

después de seleccionar todo (Ctrl-A), cortar (Ctrl-X) y pegar (Ctrl-V)
- bytes privados juffed.exe: 8,488K Tamaño virtual: 66,700K
- pn.Exe Bytes privados: 8,580K Tamaño virtual: 63,712K

Tenga en cuenta que, mientras se desplaza (Pg Down/Pg Up presionado), JuffEd parecía consumir más CPU que el Bloc de notas del programador.

Combinadas EXE y DLL tamaños:
- 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

La comparación anterior no es justa porque JuffEd no se compiló con Visual Studio 2005, que debería generar binarios más pequeños.

Answer 7

Qt es un marco muy agradable, pero hay una penalización de rendimiento. Esto tiene que ver principalmente con la pintura. Qt usa su propio procesador para pintar todo: texto, rectángulos, lo que quieras ... Para el sistema de ventanas subyacente, cada aplicación Qt parece una sola ventana con un gran mapa de bits dentro. Sin ventanas anidadas, sin nada. Esto es bueno para una representación sin parpadeos y un control máximo sobre la pintura, pero esto tiene el precio de renunciar por completo a cualquier posibilidad de aceleración de hardware. La aceleración de hardware todavía se nota hoy en día, p. al llenar rectángulos grandes en un solo color, como suele ser el caso en los sistemas de ventanas.

Dicho esto, Qt es "lo suficientemente rápido" en casi todos los casos.

En su mayoría noto lentitud cuando se ejecuta en una Macbook cuyo ventilador de la CPU es muy sensible y cobrará vida después de unos pocos segundos de moderada actividad de la CPU. Usar el mouse para desplazarse en una aplicación Qt carga la CPU mucho más que desplazarse en una aplicación nativa. Lo mismo ocurre con el cambio de tamaño de ventanas.

Como dije, Qt es lo suficientemente rápido, pero si le preocupa el agotamiento de la batería, o si le preocupa el cambio de tamaño de la ventana muy suave, entonces no tiene más remedio que volverse nativo.

Dado que parece que considera un inicio de aplicación de 3 segundos "rápido", no parece que le interese en absoluto el rendimiento de Qt. Consideraría 3 segundos de inicio lento como perro, pero las opiniones sobre eso varían de forma natural.

Answer 8

Simplemente respondiendo mi experiencia en caso de que todavía no lo haya resuelto o cualquier otra persona esté buscando más experiencia. Recientemente desarrollé una aplicación bastante pesada (QGraphicsView, OpenGL QGraphicsView, QtSQL, acceso a la base de datos, ...) con Qt 4.7 Y también soy un seguidor del rendimiento. Eso incluye el rendimiento de inicio, por supuesto, me gusta que mis aplicaciones se muestren casi al instante, por lo que dedico bastante tiempo a eso.

Velocidad: Fantástico, no tengo ninguna queja. Mi aplicación pesada que necesita crear instancias de al menos 100 widgets solo al inicio (concedido, muchos de ellos son QLabels) se inicia en una fracción de segundo (no noto ninguna demora entre el doble clic y la ventana que aparece).

Memoria: Esta es la parte mala, Qt con muchos subsistemas en mi experiencia usa una notable cantidad de memoria. Entonces, nuevamente esto cuenta para el uso de muchos subsistemas, QtXML, QtOpenGL, QtSQL, QtSVG, lo que sea, lo uso. Mi aplicación actual en el arranque se las arregla para utilizar alrededor de 50 MB, pero se pone en marcha la velocidad del rayo y responde con rapidez, así

Facilidad de programación/API: Qt es una alegría absoluta de usar, a partir de sus contenedores a sus clases widget para sus módulos Al mismo tiempo, hace que el sistema de gestión de la memoria sea sencillo (QObject) y mantiene un excelente rendimiento.Siempre he escrito win32 puro antes de esto y voy a nunca volver. Por ejemplo, con las clases QtConcurrent pude cambiar una invocación de método de myMethod(arguments) a QtConcurrent::run(this, MyClass::myMethod, arguments) y con una sola línea se enhebró un método de procesamiento pesado no GUI. Con un QFuture y QFutureWatcher pude monitorear cuando el hilo había terminado (ya sea con señales o simplemente con la verificación del método). ¡Qué facilidad de uso! Diseño muy elegante por todas partes.

Así, en retrospectiva: muy buen rendimiento (incluyendo el inicio de aplicaciones), uso bastante alto de memoria si se utilizan muchos submódulos, fantástica activos y de posibilidades, multiplataforma

Answer 9

Una vez hice una aplicación para determinar el " excelencia "de un número (ya sea primo o compuesto).

Intenté por primera vez una GUI de Qt, y me llevó 5 horas devolver la respuesta de 1.299.827 en una computadora con 8GB de RAM y una AMD 1090T @ 4GHz sin ejecutar ningún otro proceso en Linux.

Mi segundo intento usé un QProceso de una aplicación de consola que usaba exactamente el mismo código. En una computadora portátil con 1,3 GB de RAM y una CPU de 1,4 GHz, la respuesta llegó sin retraso perceptible.

No negaré, sin embargo, que es mucho más fácil que GTK + o Win32, y maneja las cosas bastante bien, pero separa el procesamiento intensivo TOTALMENTE de la GUI si lo usa.