Existem muitos estudos comparativos e disponíveis online quando se trata do desempenho em tempo de execução de aplicativos criados usando um idioma ou outro. Alguns dirigidos por empresas, outros acadêmicos, outros apenas relatos de experiências pessoais.

Também obtemos uma parcela decente de estudos comparativos sobre os efeitos colaterais de uma linguagem de programação e suas ferramentas, como:

• tempos de construção,
• probabilidade de detecção de erros pós-produção,
• poder expressivo,
• etc ...

No entanto, recentemente fiquei cada vez mais chateado com o consumo de memória dos meus programas do que qualquer outra coisa. Isso pode advir do fato de que, enquanto a Lei de Moore está do nosso lado para o desempenho bruto, percebemos que outros gargalos são mais importantes. Isso e eu não costumo atualizar meu hardware de vez em quando, e tenho alguns "antigos" (leia o Pentium 4 de 3.6GHz e 2005-2006 com 4 GB de RAM) que hoje em dia são pressionados para serem utilizáveis ​​em aplicativos grandes sem exigindo que eu tenha um grande problema para extrair todo o suco deles (escolha de SO, interface do usuário, ajustes de serviços e daemons, escolha de aplicativos a serem usados ​​para uma tarefa ou outra ...). Honestamente, às vezes eu ligo topou procexpchoro ao ver a memória usada pelos programas mais inocentes.

Eu posso resolver isso, mantendo-me pressionado na direção listada acima, e essencialmente tentando me limitar e os programas que uso (eu gosto muito de programas cli por esse motivo, eu acho), mas também não posso deixar de pensar que talvez estejamos fazendo errado.

Ferramentas modernas para necessidades modernas

Obviamente, idiomas de nível superior são sem dúvida melhores e justificam seu valor de peso morto. Algumas escolhas de design foram feitas por boas (ou supostamente bem-intencionadas) razões na época, em muitas cadeias de ferramentas. Bibliotecas compartilhadas, modelos de memória, pré-processadores, sistemas de tipos, etc ... Mas alguns podem ser mais viáveis ​​que outros com nosso hardware moderno, e eu ficaria curioso para ler alguns estudos sérios sobre o assunto.

Então, minha pergunta é: existe um pendente no jogo Benchmarks e outros que se concentram na comparação do consumo de memória de tempo de execução dos idiomas?

E ainda mais, existem alguns estudos que fazem referência cruzada com outros parâmetros (semelhante ao que este artigo fez, por exemplo, para outros critérios, também baseado no jogo Benchmarks )?

^{Eu encontrei algumas informações parciais, então começarei a compilar minhas descobertas em minha própria resposta. Por favor, não deixe que isso impeça você de contribuir com suas próprias respostas (ou editar esta).}

Literatura existente:

• Uma comparação empírica de 7 linguagens de programação - Prechelt (2000) [ PDF ]

  Um pouco datada, mas cobre parte do material que me interessa e fornece uma visão do uso e da expressividade da memória de tempo de execução. Os resultados podem diferir bastante agora, mas é um começo interessante.

• Velocidade, tamanho e confiabilidade das linguagens de programação - Marceau (2009) [ blog ]

• Código usado, formas usadas no tempo do jogo de benchmarks [ u32 , u32q , u64 , u64q ]

  Embora não cubra o consumo de memória em tempo de execução, o trabalho de Marceau é mais ou menos o tipo de referência ou estudo empírico que eu gostaria de encontrar para esse critério, em termos de conteúdo e qualidade. Um bom exemplo do que estou procurando, apenas para métricas diferentes. O segundo artigo é um acompanhamento encontrado no site Benchmarks Game e foi publicado logo após (e que faz referência) ao trabalho de Marceau, com telas mais recentes e mais idiomas, embora ainda sem detalhes da memória de tempo de execução. Cada gráfico nestas páginas conduz então a comparação linguagem-to-linguagem que fazer proporcionar alto nível de informação de memória embora.

Isso não está respondendo à pergunta, por exemplo, mas talvez mude um pouco a perspectiva. Estou tendo em mente a transcrição do chat, para definir o tom desta resposta-comentário que certamente será objeto de muitos votos negativos.

Existem pessoas, fornecedores de hardware, fornecedores de ferramentas e programadores preocupados com a eficiência. Por enquanto, será uma preocupação crescente para eles e todos nós. Essas preocupações estão enraizadas nos dispositivos móveis, particularmente nos monstros de alta potência, que consomem bateria, com as maiores telas e os rádios mais fortes.

Para dar mais um passo para trás, parte da razão pela qual nos encontramos na situação atual, com estruturas relativamente grandes e um pouco de desconsideração pela eficiência geral, além das melhorias de hardware, é um legado. A compatibilidade com sistemas legados nos fortalece com a compatibilidade. Não é tanto a culpa dos tempos de execução de nível superior, pois eles são essencialmente o mesmo tempo de execução, atuando bastante eficiente e com desempenho quando usado em um ambiente operacional diferente (por exemplo, Xbox, Windows Mobile pré 7/8 / surface, java micro framework etc).

Compare a extensão da compatibilidade que um desktop possui com seu software legado com a extensão de compatibilidade que um dispositivo móvel possui.

Com os dispositivos móveis, os fabricantes de dispositivos envidam alguns esforços para garantir alguma compatibilidade, mas não fizeram da compatibilidade um fundamento básico. Quando a escolha é entre continuar a fornecer compatibilidade e avançar o design do sistema móvel, o sistema móvel avança.

Para desktops, o oposto parece verdadeiro. Se uma mudança significativa de impacto atinge os profissionais de marketing ou os adotantes precoces de maneira errada, ela fornece os recursos necessários e o redesenho necessário para a sala dos fundos muitas vezes. Em algum momento, lembro-me de rumores de que nós, usuários do Windows, encontraríamos um sistema de arquivos completamente novo e dramático com o Windows XP, depois no Vista, depois o mesmo no Seven e, finalmente, novamente no Oito, mas não, apenas melhorando gradualmente desde vimos pela primeira vez no Windows2000? O novo sistema de arquivos ficou parado por um longo tempo, foi descartado e, no entanto, os rumores decidem a história depois disso, não posso dizer. Esse é provavelmente o maior caso conhecido, mas tenho certeza de que não é o único grande caso.

Mesmo com os tablets e sistemas operacionais mais recentes, a Microsoft que moldou o mercado agora está entrelaçada em um confronto mortal com não apenas os consumidores, mas uma sombra de si mesma do departamento de desktops. O tablet tinha que ter uma interoperabilidade significativa com a contraparte da área de trabalho. Não, ele não conseguiu se encaixar perfeitamente com ele, devido às diferenças de arquitetura, mas também devido à natureza arcaica dos fundamentos da área de trabalho que fez sacrifícios significativos.

Agora, certamente, o Windows é o alvo fácil de qualquer tipo de crítica a essa situação, mas outras plataformas estão longe de "livres de pecado". Há muitas relíquias ocultas no ecossistema Linux que, com certeza, causam grande consternação por melhorias sistemáticas.

A economia tem um papel importante nessa equação; como financiamos nossos computadores e aplicativos em um e como eles são financiados por outro seguem padrões surpreendentemente diferentes. Onde Wintel já influenciou fortemente a obsolescência, a Apple e o Google a transformaram em um cronograma quase estrito. Isso está mais fora do curso do que eu pretendia, então deixarei como está e deixarei que os leitores a tirem de lá.

Se e quando os grandes fornecedores mudam seus modelos de obsolescência e preços, eles podem começar a avançar com mudanças de escala maiores a uma taxa mais uniforme. As estruturas de nível superior orientadas pelas linguagens de ordem mais alta diminuirão de certa forma, pois serão capazes de realizar suas tarefas de alto nível com uma eficiência semelhante a um nível mais baixo, porque a ineficiente compatibilidade intermediária e as camadas de baixo nível serão reduzidas. ser drasticamente reduzido, se não for eliminado.