Hay muchos estudios comparativos y disponibles en línea cuando se trata del rendimiento en tiempo de ejecución de las aplicaciones creadas con un idioma u otro. Algunos impulsados ​​por corporaciones, algunos académicos, algunos solo informes de experimentos personales.

También obtenemos una buena cantidad de estudios comparativos sobre los efectos secundarios de un lenguaje de programación y sus herramientas, como:

• tiempos de construcción,
• probabilidad de detección de errores de postproducción,
• poder expresivo,
• etc ...

Sin embargo, recientemente he estado cada vez más desanimado por el consumo de memoria de mis programas más que cualquier otra cosa. Esto puede deberse al hecho de que, si bien la Ley de Moore está de nuestro lado para un rendimiento bruto, nos hemos dado cuenta de que otros cuellos de botella importan más. Eso, y no tiendo a actualizar mi hardware de vez en cuando, y tengo algunos "viejos" (lea 2005-2006 3.6GHz Pentium 4 con 4GB de RAM) que hoy en día son difíciles de usar para aplicaciones grandes sin lo que me obliga a pasar por grandes problemas para exprimirles todo el jugo (elección de sistema operativo, interfaz de usuario, ajustes de servicios y demonios, elección de aplicaciones para usar en una tarea u otra ...). Honestamente, a veces enciendo topo procexplloro al ver la memoria utilizada por los programas más inocentes.

Puedo abordar esto presionando en la dirección mencionada anteriormente, y esencialmente tratando de limitarme a mí mismo y a los programas que uso (supongo que me encantan los programas cli por esa razón), pero tampoco puedo evitar pensar que tal vez lo estamos haciendo mal.

Herramientas modernas para necesidades modernas

Por supuesto, los idiomas de nivel superior son posiblemente mejores y justifican su valor de peso muerto. Algunas elecciones de diseño se hicieron por buenas (o supuestamente bien intencionadas) razones en ese momento, en muchas cadenas de herramientas. Bibliotecas compartidas, modelos de memoria, preprocesadores, sistemas de tipos, etc. Pero algunos podrían ser más viables que otros con nuestro hardware moderno, y me gustaría leer algunos estudios serios sobre el tema.

Entonces, mi pregunta es, ¿hay un pendiente para el Juego de Benchmarks y otros que se centren en una comparación del consumo de memoria de tiempo de ejecución base de los idiomas?

Y aún más, ¿hay algunos estudios que hagan referencias cruzadas de esto con otros parámetros (similar a lo que hizo este artículo , por ejemplo, para otros criterios, también basados ​​en el Juego de puntos de referencia )?

^{He encontrado información parcial, así que comenzaré a compilar mis hallazgos en mi propia respuesta. Por favor, no permita que eso le impida contribuir con sus propias respuestas (o editar esta).}

Literatura existente:

• Una comparación empírica de 7 lenguajes de programación - Prechelt (2000) [ PDF ]

  Un poco anticuado, pero cubre parte del material que me interesa y da una idea del uso y la expresividad de la memoria en tiempo de ejecución. Los resultados pueden diferir mucho ahora, pero es un comienzo interesante.

• Velocidad, tamaño y confiabilidad de los lenguajes de programación - Marceau (2009) [ blog ]

• Código utilizado, formas de tiempo utilizado del juego de referencia [ u32 , u32q , u64 , u64q ]

  Aunque no cubre el consumo de memoria en tiempo de ejecución, el trabajo de Marceau es más o menos el tipo de referencia o estudio empírico que estaría dispuesto a encontrar para ese criterio, en términos de contenido y calidad. Un buen ejemplo de lo que busco, solo para diferentes métricas. El segundo artículo es un seguimiento que se encuentra en el sitio de Benchmarks Game y que se publicó poco después (y que hace referencia) al trabajo de Marceau, con pantallas más recientes y más idiomas, aunque todavía sin detalles de memoria de tiempo de ejecución. Cada gráfico en estas páginas conduce entonces a la comparación de lengua a lengua que hacen proporcionar información de la memoria de alto nivel sin embargo.

Esto no responde la pregunta por decir, pero quizás cambia un poco la perspectiva. Estoy teniendo en cuenta la transcripción del chat, para establecer el tono de este comentario de respuesta que seguramente será objeto de muchos votos negativos.

Hay personas, proveedores de hardware, proveedores de herramientas y programadores que están preocupados por la eficiencia. Por el momento, será una preocupación creciente para ellos y para todos nosotros. Esas preocupaciones están enraizadas en los dispositivos móviles, particularmente en los monstruos de alta potencia y batería con las pantallas más grandes y las radios más fuertes.

Para dar un paso más atrás, parte de la razón por la que nos encontramos en la situación en la que nos encontramos hoy, con marcos comparativamente masivos y un ligero desprecio por la eficiencia general, más allá de las mejoras de hardware, es un legado. La compatibilidad con los sistemas heredados nos consolida con la compatibilidad además de la compatibilidad. No es tanto culpa de los tiempos de ejecución de nivel superior, ya que esencialmente son el mismo tiempo de ejecución que actúa de manera bastante eficiente y eficiente cuando se usa en un entorno operativo diferente (por ejemplo, Xbox, Windows Mobile pre 7/8 / Surface, Java Micro Framework , etc.)

Compare el grado de compatibilidad que posee una computadora de escritorio con su software heredado con el grado de compatibilidad que posee un dispositivo móvil.

Con los dispositivos móviles, los productores de dispositivos hacen un esfuerzo para garantizar cierta compatibilidad, pero no han hecho de la compatibilidad un fundamento fundamental. Cuando la elección es entre continuar proporcionando compatibilidad y avanzar el diseño del sistema móvil, el sistema móvil avanza.

Para las computadoras de escritorio, lo contrario parece ser cierto. Si un cambio importante afecta a los vendedores o los primeros en adoptar erróneamente, empuja las características necesarias y el rediseño necesario a la trastienda muchas veces. En algún momento recuerdo los rumores en el sentido de que nosotros, como usuarios de Windows, encontraríamos un sistema de archivos completamente nuevo y dramáticamente con Windows XP, luego en Vista, más tarde lo mismo para Seven, y finalmente nuevamente en Ocho, pero no, solo mejorado gradualmente desde lo vimos por primera vez en Windows 2000? El nuevo sistema de archivos permaneció por mucho tiempo, fue descartado y, sin embargo, los rumores deciden la historia después de eso, no puedo decirlo. Ese es probablemente el caso más grande conocido, pero estoy seguro de que no es el único gran caso.

Incluso con las tabletas y sistemas operativos móviles más recientes, Microsoft, que una vez dio forma al mercado, ahora se entrelaza en un combate mortal no solo con los consumidores, sino también una sombra del departamento de computadoras de escritorio. La tableta tenía que tener una interoperabilidad significativa con la contraparte de escritorio. No, no podía jugar perfectamente con él, debido a las diferencias de arquitectura, pero también debido a la naturaleza arcaica de las bases del escritorio hizo sacrificios significativos.

Ahora, ciertamente, Windows es el blanco fácil para cualquier tipo de crítica a esta situación, pero otras plataformas están lejos de ser "libres de pecado". Hay muchas reliquias al acecho en el ecosistema de Linux que estoy seguro causan una gran consternación para la mejora sistemática.

La economía juega un papel importante en esta ecuación; cómo financiamos nuestras computadoras y aplicaciones en uno, y cómo se financian en el otro, siguen patrones asombrosamente diferentes. Donde Wintel alguna vez influyó fuertemente en la obsolescencia, Apple y Google lo convirtieron en un horario casi estricto. Esto está más alejado de lo esperado, así que lo dejaré como está y dejaré que los lectores lo tomen desde allí.

Si los grandes proveedores cambian sus modelos de obsolescencia y fijación de precios, pueden comenzar a avanzar con cambios a mayor escala a un ritmo más uniforme. Esos marcos de nivel superior que son impulsados ​​por los lenguajes de orden superior se reducirán de alguna manera, ya que podrán lograr su tarea de alto nivel con una eficiencia similar a un nivel más bajo porque la ineficiente compatibilidad intermedia y las capas de bajo nivel ser reducido drásticamente, si no eliminado.