Olá pessoal! Nossa equipe está desenvolvendo um IDE para trabalhar com a API TestMace . Em um de nossos artigos anteriores, os leitores apontaram para o consumo exorbitante de memória de aplicativos de elétrons. Bem, chegou a hora dos números :) Neste artigo, o autor estima o consumo de memória de aplicativos de janela única escritos usando vários kits de ferramentas. Boa leitura!
Encontrando o conjunto perfeito de ferramentas para criar uma GUI, decidi medir a quantidade de memória que eles ocupavam.
Na verdade, eu queria descobrir qual deles requer a menor quantidade de memória para um programa que consiste em uma janela vazia. Neste artigo, vou falar sobre os resultados.
Isenção de responsabilidade
Este artigo fornece informações sobre a memória ocupada pelo programa ao usar várias ferramentas, estruturas e bibliotecas para criar GUIs no Linux. Todas as medições foram feitas no mesmo computador com o Ubuntu 19.04 (Disco Dingo) x86_64 usando o programa Ksysguard, que fornece dados sobre a memória interna consumida pelos aplicativos. Não reinstalei o sistema especificamente para o teste. Foi realizado no meu ubíquo Ubuntu, no qual vários pacotes já estavam instalados, o que poderia afetar / distorcer os resultados.
Para algumas ferramentas, eu até adicionei medidas obtidas no Windows 10, que dificilmente podem ser comparadas ao Linux, mas é interessante ver.
Quero observar que minhas medidas não têm valor científico. Tendo outros dados iniciais, você pode obter resultados completamente diferentes.
Não é tão fácil quanto parece
Então, o que precisamos medir? Memória virtual (VSZ)? Memória residente (RSS)? Possui RSS? RSS compartilhado?
Resumindo, então ... acredito que, ao comparar dois programas idênticos desenvolvidos usando diferentes conjuntos de ferramentas, a maneira mais precisa é medir a quantidade de memória interna ocupada por um processo com smaps. O Ksysguard usa smaps para exibir informações detalhadas da memória. No entanto, desde o início, em meu experimento, usei os dados do painel de consumo de RAM por padrão e só então percebi que os smaps fornecem números mais precisos. Para garantir a consistência dos dados, usei as informações do painel RAM padrão para todas as ferramentas apresentadas na lista, embora, muito provavelmente, usando uma interface com uma descrição detalhada do consumo de memória, uma situação semelhante pudesse ser vista.
Se em mais detalhes, então ... neste artigo, eu não teria espaço suficiente para lições sobre gerenciamento de memória no Linux e, além disso, já existem muitos materiais dignos sobre esse assunto: ELC: Quanta memória os aplicativos estão realmente usando? , O sistema de arquivos / proc , pseudo-sistema de informações do processo - Visão geral do Linux Memory Management , Gerenciamento de memória
Lista de ferramentas e seus indicadores de memória
Nem uma palavra mais. Aqui estão meus resultados:
Fiquei surpreso com a gula de Flutter, uma vez que ela foi originalmente concebida como uma estrutura para criar uma GUI para dispositivos móveis.UPD (meus agradecimentos a kirbyfan64sos ): O Flutter Desktop ainda está nos estágios iniciais de desenvolvimento e todas as compilações estão depurando. Isso significa que todos os criadores de perfil (como o Observatory) estão ativos, todas as instruções de depuração estão ativadas e o compilador AoT está desativado. Será interessante verificar novamente os dados usando a versão build.
Não direi que fiquei impressionado com o desempenho do Electron.
Com o HorusUI, eu esperava um valor aproximado de 20 MB, porque ele usa o OpenGL e o modo de renderização imediata da GUI. Não entendo por que o número saiu mais.
As estruturas Swing e JavaFX Java também mostraram resultados interessantes. Ambos são extremamente insaciáveis e, se você não tiver certeza de qual deles seria adequado para o seu novo projeto Java, parece razoável optar pela estrutura JavaFX mais conveniente e moderna, embora você precise preenchê-la com um pouco mais de memória. Mas se sua memória vale seu peso em ouro, é claro que escolha Swing.
O Qt também mostrou números muito interessantes e acabou sendo muito mais voraz do que a maioria das outras ferramentas populares. Vale ressaltar que a maior parte da memória ocupada é a quantidade consumida pelo driver amdgpu instalado no meu sistema. Talvez isso ocorra porque os buffers do OpenGL são armazenados localmente. O mesmo pode ser visto com o SDL2: um programa sem OpenGL consome 1,1 MB e, com ele, até 14 MB.
WxWidgets e LCL estão bem posicionados nessa comparação. Apesar de serem invólucros sobre outras ferramentas para a GUI, o custo dos recursos é mínimo. Estou impressionado com a idéia da possibilidade de transferir o back-end do Gtk +, por exemplo, para o Qt, garantindo assim a independência das ferramentas.
Também destacarei o Nuklear, simplesmente porque, ao que me parece, ele tem um modo de renderização imediata da GUI muito legal. Se você não ficar confuso com o uso do framebuffer bruto X11, o aplicativo de janela única ocupará apenas 0,624 MB, o que parece muito impressionante.
Conclusão
Se você esperava ver alguma conclusão generalizada aqui, receio ter que decepcioná-lo.