¿Por qué los tamaños de los programas son tan grandes?

Si miramos el programa antiguo Netscape Navigator o una versión anterior de Microsoft Word, esos programas tenían menos de 50 MB de tamaño. Ahora, cuando instalo Google Chrome, es de 200 MB y la versión de escritorio de Slack es de 300 MB. Leí sobre alguna regla de que los programas tomarán toda la memoria disponible, no importa cuánto sea, pero ¿por qué?

¿Por qué los tamaños actuales de los programas son tan grandes en comparación con hace 10 o 15 años? Los programas no realizan muchas más funciones y no se ven muy diferentes. ¿Qué es ahora el recurso porcino?

"Verse muy diferente" es una cuestión de percepción. Los gráficos de hoy tienen que verse bien en resoluciones de pantalla totalmente diferentes de lo que solían ser, con el resultado de que una imagen de 100x100 que solía ser lo suficientemente buena para un logotipo ahora se vería horriblemente pegajosa. Ha tenido que ser reemplazado por una imagen de 1000x1000 de la misma cosa, que es un factor de 100 allí mismo. (Sé que puede usar gráficos vectoriales en su lugar, pero eso solo enfatiza el punto: el código de representación de gráficos vectoriales ha tenido que agregarse a sistemas que no lo necesitaban antes, por lo que esto es solo una compensación de un tipo de aumento de tamaño a otro.)

"Trabajar de manera diferente" es también una cuestión de percepción. El navegador de hoy hace masivamente más cosas que una desde 1995. (Intente navegar por Internet con una computadora portátil histórica un día lluvioso, encontrará que es casi inutilizable). No muchos de ellos se usan mucho, y los usos pueden ser completamente inconscientes de 90 % de ellos, pero están ahí.

Además de eso, por supuesto, está la tendencia general de dedicar menos tiempo a optimizar las cosas por espacio y más a introducir nuevas características. Este es un efecto secundario natural de computadoras más grandes, más rápidas y más baratas para todos. Sí, sería posible escribir programas que sean tan eficientes en recursos como lo fueron en 1990, y el resultado sería asombrosamente rápido y resbaladizo. Pero ya no sería rentable; su navegador tardaría diez años en completarse, momento en el cual los requisitos habrían cambiado por completo. La gente solía programar con extrema atención a la eficiencia porque las máquinas pequeñas y lentas de antaño los obligaban a hacerlo, y todos los demás también lo hacían. Tan pronto como esto cambió, el cuello de botella para el éxito del programa pasó de ser capaz de funcionar en absoluto a corrermás y más cosas brillantes , y ahí es donde estamos ahora.

Si compara Netscape Navigator con un navegador moderno, hay una gran diferencia en la funcionalidad. Simplemente compare la especificación HTML 3.2 (51 páginas cuando hago una vista previa de impresión) con la especificación HTML actual (la versión PDF es de 1155 páginas). Eso es un aumento de 20x en tamaño.

¡Netscape Navigator no tenía un DOM y no tenía CSS! No hubo cambios dinámicos del documento, ni JavaScript modificó el DOM ni las hojas de estilo. Sin pestañas Sin audio ni video. Un navegador moderno es un programa mucho más complejo.

Una razón es que los datos empaquetados dentro de las aplicaciones son más grandes porque son de mayor resolución y calidad. En los días de Netscape, un ícono tenía como máximo 32x32 píxeles, con una profundidad máxima de 8 bits (posiblemente solo 4), mientras que ahora es algo así como 64x64 y está en color verdadero con transparencia, lo que significa una profundidad de 32 bits. Eso es 16 veces más grande. Y el espacio es tan barato que las personas a menudo ni siquiera se molestan en marcar la opción "comprimida" al generar un PNG.

Otra razón es que las aplicaciones hoy en día llevan una cantidad alucinante de datos con ellas, que las aplicaciones más antiguas no. Existen aplicaciones hoy que se envían junto con una presentación de "inicio" en video .

Otra razón es que los lenguajes de programación actuales tienden a combinarse con entornos de tiempo de ejecución enriquecidos, que son bastante grandes, con una melodía de 100 MB cada uno. Incluso si no utiliza todas las características de su entorno de tiempo de ejecución, aún tiene que empaquetar todo con su aplicación.

Pero la razón principal es que hoy existen toneladas y toneladas de bibliotecas que podemos usar en nuestras aplicaciones, y hemos desarrollado una cultura de uso de bibliotecas para evitar la reinvención constante de la rueda. Por supuesto, una vez que comience a usar las bibliotecas, aparecen varias preguntas, y hemos desarrollado el hábito de darles las respuestas más liberales:

• ¿Vale la pena incluir otra biblioteca si solo va a ser utilizada por una de mis funciones? - si.

• ¿Vale la pena incluir otra biblioteca si solo necesito un pequeño subconjunto de toda la riqueza de funcionalidad que ofrece esa biblioteca? - si.

• ¿Vale la pena incluir otra biblioteca si su inclusión solo me salvará de 2 días de trabajo? - si.

• ¿Vale la pena incluir varias bibliotecas que tienen más o menos el mismo propósito solo porque los diferentes programadores en mi nómina ya están familiarizados con diferentes bibliotecas? - si.

  (Tenga en cuenta que solo estoy observando estas tendencias, no estoy haciendo ninguna declaración sobre si estoy de acuerdo o en desacuerdo con ellas).

Otra razón que vale la pena mencionar es que al intentar decidir qué aplicación usar entre varias opciones, algunos usuarios piensan que la que ocupa más espacio tendrá más funciones, tendrá gráficos más sofisticados, etc. (lo cual es completamente absurdo, por supuesto). .)

Entonces, para concluir, ¿el software se comporta como el gas? ¿Tiende a ocupar todo el espacio disponible? En cierto sentido sí, pero no de manera alarmante. Si nos fijamos en lo que ocupa la mayor parte del espacio en nuestros paseos, para la mayoría de nosotros la respuesta es que no se trata de aplicaciones, pero los medios de comunicación tales como películas y música por el momento . El software no se ha hinchado al mismo ritmo que la capacidad de almacenamiento se ha expandido, y es poco probable que lo haga, por lo que en el futuro es probable que las aplicaciones representen una fracción insignificante del espacio de almacenamiento disponible para los usuarios.

Además de las otras respuestas, hace 10 años normalmente habría versiones separadas para versiones localizadas / internacionalizadas. Ahora, por lo general, los programas agruparán el soporte completo de localización en cada versión lanzada que rellena el tamaño del programa.

Una razón son las dependencias. Un programa con una funcionalidad rica y una buena apariencia necesita muchas cosas: cifrado, corrección ortográfica, trabajo con XML y JSON, edición de texto y muchas otras cosas. ¿De dónde vendrían? Tal vez ruedes el tuyo y lo mantengas lo más pequeño posible. Lo más probable es que use componentes de terceros (quizás de código abierto con licencia MIT) que tienen una gran cantidad de funcionalidades que realmente nunca necesita, pero una vez que necesita una sola función de un componente de terceros, a menudo tiene que transportar todo el componente. Entonces agrega más y más dependencias y a medida que ellas mismas evolucionan y crecen, su programa que depende de ellas también crece.

Si bien los gráficos / usabilidad son factores que contribuyen, hay una gran cantidad de eso que es biblioteca / código compilado en exceso.

Ejemplo de cuán pequeño puede ser el código: MenuetOS, un sistema operativo completo de 64 bits con aplicaciones potentes que cabe en un solo disquete.

Ejemplo de cuán grande puede ser el código sin una razón obvia: hice una salida de texto simple "¡Hola, mundo!" en Ada recientemente. ¡El ejecutable compilado tenía más de 1 MiB !. El mismo ejecutable en el ensamblaje es solo un KiB o 2 (y la mayor parte es ejecutable, el código de ejecución real es decenas de bytes).

Es trivialmente cierto que el software debe construirse para adaptarse a dos cosas: los usuarios y el hardware disponible. Un programa es adecuado para su propósito si hace lo que el usuario quiere de manera oportuna con el hardware a disposición del usuario. Bueno duh Pero a medida que el hardware mejora básicamente en todas las dimensiones mensurables, aumenta el número de programas discretos que pasan de no aptos a adecuados: el espacio de diseño aumenta:

• Los lenguajes de nivel superior permiten expresar ideas en menos código y tiempo que antes. Esta complejidad reducida, por el contrario, hace posible expresar ideas cada vez más complejas.
• Agrupar más datos con la aplicación puede hacer que sea instantáneamente más utilizable. Por ejemplo, probablemente no pasará mucho tiempo antes de que las aplicaciones de corrección ortográfica se incluyan en todos los idiomas conocidos por la humanidad; después de todo, solo son unos pocos gigabytes.
• Las compensaciones de hardware permiten a los desarrolladores y usuarios más opciones en el recurso que les interesa. Ver, por ejemplo, FLAC / OGG vs WAV, SVG vs PNG, índices de bases de datos.
• Las interfaces humanas a menudo intercambian lo que anteriormente equivaldría a grandes cantidades de hardware para la usabilidad. El suavizado, las altas resoluciones, la actualización rápida y el deslizamiento entre lo que equivale a paneles discretos crean una experiencia más realista y, por lo tanto, intuitiva y relatable.

Esto es definitivamente cierto con respecto a las aplicaciones de Android. Hace cuatro años, una aplicación simple ocupaba entre 2 y 5 megabytes de espacio. Hoy en día, una aplicación simple ocupa alrededor de 10-20 megabytes de espacio.

Cuanto más espacio disponible, mayor será el tamaño de la aplicación.

Creo que hay dos razones principales en el caso de Android:

• Google expandió el marco de Android, agregó muchas funcionalidades nuevas.

• A los desarrolladores ya no les importa. Las imágenes se incluyen en una resolución mucho más alta (por supuesto, las resoluciones de pantalla del teléfono inteligente aumentaron), las bibliotecas de terceros se incluyen irreflexivamente.

Mucho de esto se reduce al tiempo del desarrollador y al costo de ese tiempo. En los días en que Visual Basic llegó por primera vez a la escena, estaba compitiendo con C / C ++ y el gran golpe en contra era que podías escribir 'Hello World' en ANSI C para Windows en quizás 15K. El problema con VB era que siempre tenías el albatros de la biblioteca de tiempo de ejecución de 300K.

Ahora, podría 10 veces el tamaño de su programa VB y todavía sería solo unas K más, pero 10 veces el tamaño de su programa C / C ++ y está buscando unos MESES más de desarrollo.

Al final, la amplitud de sus aplicaciones es un pequeño precio a pagar por los enormes saltos en la producción de desarrollo, la reducción de precios y la enorme inmensidad de capacidades que nunca hubieran sido posibles en los viejos días de desarrollo hechos a mano; cuando los programas eran pequeños y rápidos pero también débiles, incompatibles entre sí, poco destacados y costosos de desarrollar.

Con el tiempo, las necesidades del usuario están evolucionando y son cada vez más exigentes, por lo que los proveedores / autores de diferentes softwares se ven obligados a satisfacer esas necesidades en nombre de la competencia.

Pero satisfacer una nueva necesidad significa a menudo agregar un nuevo código. Nuevo código significa nuevas vulnerabilidades para corregir. Arreglar nuevas vulnerabilidades puede agregar código o abrir puertas a nuevas vulnerabilidades.

Cada característica adicional para satisfacer las necesidades de un usuario puede necesitar más potencia de procesador para la velocidad (todos nos quejamos de la velocidad de este o aquel navegador), nuevos recursos gráficos para mejores efectos visuales ... etc.

Todo esto significa agregar nuevas capas de aplicaciones (código), seguridad y, a veces, hardware.

Gran parte del tamaño proviene de bibliotecas integradas. En la actualidad, muchas aplicaciones se crean utilizando electrones, lo que agrupa una gran cantidad con la aplicación. Si instala aplicaciones en Linux, generalmente son mucho más pequeñas porque gran parte de la aplicación ya está instalada a través de bibliotecas compartidas que otros programas también están utilizando.

Al construir software, si necesita la función A, importará un módulo A *. A * puede resolver A, pero A * puede resolver problemas más que A, y A * podría ser grande. Todos los módulos grandes dan como resultado el software de gran tamaño.

Tal vez no sea el mismo caso, pero algo como esto: si solo necesita imprimir "hello world" en la consola usando Java, necesita instalar JRE (> 60MB).

Si el ejemplo de Java no es bueno, intente este: si el software necesita iniciar sesión en un archivo, puede usar un módulo de registro que realmente puede hacer registros en la base de datos, a través de la red y algunas otras características, pero las funciones nunca se usan en el proyecto.

Leí sobre alguna regla de que los programas tomarán toda la memoria disponible, no importa cuánto sea, pero ¿por qué?

Eso no es del todo cierto. Los sistemas no liberarán la memoria que han consumido hasta que el sistema operativo esté bajo presión de memoria. Esta es una mejora del rendimiento. Si estaba navegando por una página con imágenes, navega lejos. Puede navegar hacia atrás, por lo tanto, necesita la imagen nuevamente. Si el sistema operativo tiene la RAM, no tiene sentido borrar la memoria hasta que esté seguro de que no la volverá a necesitar.

Borrar la memoria de inmediato quitaría los ciclos de la CPU y el ancho de banda de la memoria al usuario cuando probablemente lo más probable es que quieran que se muestren páginas web altamente receptivas en la pantalla.

El sistema operativo consumirá toda la memoria disponible que no sea de aplicación, la mayoría de la cual es para el caché del sistema de archivos.

La gestión de la memoria es un problema difícil, pero hay personas muy inteligentes trabajando en ello todo el tiempo. No se desperdicia nada a propósito y el objetivo clave es proporcionarle una computadora muy receptiva.

Puede ser cierto que los programas tienden a expandirse para llenar el espacio disponible, de manera similar a los fenómenos suburbanos donde se agregan nuevos carriles a una supercarretera bloqueada y en unos pocos años el tráfico vuelve a retroceder.

Pero si lo analizas, puedes encontrar que sus programas realmente hacen más cosas. Los navegadores, por ejemplo, ejecutan gráficos más sofisticados, tienen herramientas de desarrollo ingeniosas que no existían hace unos años, etc. También se vinculan a muchas bibliotecas, a veces usando solo una pequeña porción del código. Entonces, si bien los programas pueden aumentar de tamaño para llenar la memoria disponible, algunos de estos pueden ser motivos legítimos.

Las bibliotecas construidas sobre objetos que no están optimizados requieren más memoria para cargar, instalar y más ciclos informáticos para funcionar. El código objeto es en su mayor parte hinchado.

Simplemente recorra el código estándar de C ++ que se ejecuta para ver todas las llamadas a objetos afirmadas () para asegurarse de que sean objetos válidos. Cuando diseña capa sobre capa de objetos que encapsulan objetos, las capas subyacentes están hinchadas y opacas. Los programadores se vuelven perezosos y toman más objetos porque es más rápido que rediseñar lo que se limita a la funcionalidad necesaria. Es realmente así de simple.

Considere el tamaño del kernel de Linux C, solo el kernel, en comparación con el tamaño de las aplicaciones a medida. El kernel puede ejecutar toda la máquina. Pero no se creó tan rápido como las aplicaciones, toma tiempo lentamente para hacer la mejor funcionalidad.