Hola a todos! Nuestro equipo está desarrollando un IDE para trabajar con la API TestMace . En uno de nuestros artículos anteriores, los lectores señalaron el consumo de memoria prohibitivamente alto de las aplicaciones de electrones. Bueno, ha llegado el momento de los números :) En este artículo, el autor estima el consumo de memoria de las aplicaciones de una sola ventana escritas usando varios juegos de herramientas. Que tengas una buena lectura!
Al encontrar el conjunto perfecto de herramientas para crear una GUI, decidí medir la cantidad de memoria que ocupaban.
De hecho, quería averiguar cuál requiere la menor cantidad de memoria para un programa que consta de una ventana vacía. En este artículo hablaré sobre los resultados.
Descargo de responsabilidad
Este artículo proporciona información sobre la memoria ocupada por el programa cuando se utilizan diversas herramientas, marcos y bibliotecas para crear GUI en Linux. Todas las mediciones se realizaron en la misma computadora con Ubuntu 19.04 (Disco Dingo) x86_64 utilizando el programa Ksysguard, que proporciona datos sobre la memoria interna consumida por las aplicaciones. No reinstalé el sistema específicamente para la prueba. Se realizó en mi ubicuo Ubuntu, en el que ya se instalaron varios paquetes, lo que podría afectar / distorsionar los resultados.
Para algunas herramientas, incluso agregué medidas obtenidas en Windows 10, que difícilmente se pueden comparar con Linux, pero es interesante ver.
Quiero señalar que mis medidas no son de valor científico. Al tener otros datos iniciales, puede obtener resultados completamente diferentes.
No es tan fácil como parece
Entonces, ¿qué necesitamos medir? Memoria virtual (VSZ)? ¿Memoria residente (RSS)? ¿RSS propio? RSS compartido?
En resumen, entonces ... Creo que al comparar dos programas idénticos desarrollados usando diferentes conjuntos de herramientas, será más preciso medir la cantidad de proceso de su propia memoria con smaps. Ksysguard utiliza smaps para mostrar información detallada de la memoria. Sin embargo, desde el principio, en mi experimento, utilicé los datos del panel de consumo de RAM de forma predeterminada, y solo entonces me di cuenta de que los smaps dan números más precisos. Para garantizar la coherencia de los datos, utilicé la información del panel RAM predeterminado para todas las herramientas presentadas en la lista, aunque, muy probablemente, utilizando una interfaz con una descripción detallada del consumo de memoria, podría verse una situación similar.
Si con más detalle, entonces ... en este artículo no habría tenido suficiente espacio para las lecciones sobre administración de memoria en Linux, y además, ya hay muchos materiales valiosos sobre este tema: ELC: ¿Cuánta memoria están usando realmente las aplicaciones? , El sistema de archivos / proc , proc - pseudo-sistema de información de proceso , Descripción general de la gestión de memoria de Linux , Gestión de memoria
Lista de herramientas y sus indicadores de memoria.
Ni una palabra más. Aquí están mis resultados:
Me sorprendió la gula de Flutter, dado que originalmente fue concebido como un marco para crear una GUI para dispositivos móviles.UPD (mi agradecimiento a kirbyfan64sos ): Flutter Desktop todavía se encuentra en las primeras etapas de desarrollo, y todas las compilaciones se están depurando. Esto significa que todos los perfiladores (como el Observatorio) están activos, todas las declaraciones de depuración están habilitadas y el compilador AoT está deshabilitado. Será interesante volver a verificar los datos utilizando la compilación de lanzamiento.
No diré que me sorprendió la actuación de Electron.
Con HorusUI, esperaba una cifra aproximada de 20 MB, porque usa OpenGL y el modo de representación inmediata de la GUI. No entiendo por qué la cifra salió más.
Los frameworks Swing y JavaFX Java también han mostrado resultados interesantes. Ambos son extremadamente insaciables, y si no está seguro de cuál sería el adecuado para su nuevo proyecto Java, entonces parece razonable optar por el marco JavaFX más conveniente y moderno, aunque tendrá que llenarlo con un poco más de memoria. Pero si su memoria vale su peso en oro, entonces, por supuesto, elija Swing.
Qt también mostró cifras muy interesantes y resultó ser mucho más voraz que la mayoría de las otras herramientas populares. Vale la pena señalar que la mayor parte de la memoria que ocupa es la cantidad consumida por el controlador amdgpu instalado en mi sistema. Tal vez esto se deba a que los búferes OpenGL se almacenan localmente. Lo mismo se puede ver con SDL2: un programa sin OpenGL consume 1.1 MB y con él hasta 14 MB.
WxWidgets y LCL están bien ubicados en esta comparación. A pesar de que son envoltorios sobre otras herramientas para la GUI, el costo de los recursos es mínimo. Me impresiona la idea de la posibilidad de transferir el backend de Gtk +, por ejemplo, a Qt, garantizando así la independencia de las herramientas.
También destacaré Nuklear, simplemente porque, me parece, tiene un modo de renderizado inmediato GUI muy bueno. Si no está confundido por el uso del framebuffer X11 sin procesar, su aplicación de una sola ventana ocupará solo 0.624 MB, lo que se ve muy impresionante.
Conclusión
Si esperaba ver alguna conclusión generalizada aquí, me temo que tengo que decepcionarlo.