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

183

Si nos fijamos en el antiguo programa Netscape Navigator o en una versión anterior de Microsoft Word, esos programas tenían un tamaño inferior a 50 MB. Ahora, cuando instalo google chrome es de 200 MB y la versión de escritorio de Slack es de 300 MB. Leí acerca de alguna regla de que los programas se llevará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 están haciendo muchas más funciones y no se ven muy diferentes. ¿Qué es lo que es el recurso de recursos ahora?

    
pregunta Niklas Rosencrantz 24.09.2015 - 09:24
fuente

15 respuestas

264

"Mirar muy diferente" es una cuestión de percepción. Los gráficos de hoy tienen que verse bien con resoluciones de pantalla totalmente diferentes de lo que solían ser, con el resultado de que una imagen de 100x100 que solía ser más que 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í. (Sé que puede usar gráficos vectoriales en su lugar, pero eso solo enfatiza el punto: el código de procesamiento de gráficos vectoriales se tuvo que agregar a los sistemas que no lo necesitaban antes, así que esto es solo una compensación de un tipo de aumento de tamaño a otro.)

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

Además de eso, por supuesto, está la tendencia general a dedicar menos tiempo a optimizar las cosas por espacio y más a introducir nuevas funciones. 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 increíblemente 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 ejecutar en absoluto a ejecutar más y más cosas brillantes , y ahí es donde estamos ahora.

    
respondido por el Kilian Foth 24.09.2015 - 09:33
fuente
108

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

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

    
respondido por el JacquesB 24.09.2015 - 09:46
fuente
79

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

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

Otra razón es que los lenguajes de programación de hoy en día tienden a ir acompañados de entornos ricos en tiempo de ejecución, que son bastante grandes, por una suma de 100 MB cada uno. Incluso si no usa 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 en día existen toneladas y toneladas de bibliotecas que podemos usar en nuestras aplicaciones, y hemos desarrollado una cultura de usar bibliotecas para evitar la constante reinvención de la rueda. Por supuesto, una vez que comienzas 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? - sí.

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

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

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

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

Otra razón que vale la pena mencionar es que cuando se trata de decidir qué aplicación usar entre varias opciones, algunos usuarios piensan que la que ocupe más espacio tendrá más características, tendrá gráficos más sofisticados, etc. (que es un completo disparate, por supuesto).

Entonces, para concluir, ¿el software se comporta como un gas? ¿Tiende a ocupar todo el espacio disponible? En cierto sentido, sí, pero no de forma alarmante. Si observamos qué ocupa la mayor parte del espacio en nuestros discos, para la mayoría de nosotros la respuesta es que no se trata de aplicaciones, sino de medios como películas y música con mucho . El software no se ha hinchado a la misma velocidad que la capacidad de almacenamiento, 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 usuarios.

    
respondido por el Mike Nakis 24.09.2015 - 11:30
fuente
16

Además de los otros usuarios, hace 10 años, típicamente habría versiones separadas para versiones localizadas / internacionalizadas. Ahora es generalmente el caso de que los programas agruparán el soporte completo de localización en cada versión lanzada que rellene el tamaño del programa.

    
respondido por el Eterm 24.09.2015 - 10:32
fuente
13

Una de las razones es dependencias. Un programa con una gran funcionalidad y 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 haces tu propio rollo y lo mantienes lo más pequeño posible. Lo más probable es que utilice componentes de terceros (tal vez de código abierto con licencia MIT) que tienen una gran cantidad de funcionalidad que realmente nunca necesita, pero una vez que necesita una única función de un componente de terceros, a menudo tiene que llevar todo el componente. Así que agrega más y más dependencias y, a medida que ellos mismos evolucionan y aumentan, su programa que depende de ellos también crece.

    
respondido por el sharptooth 24.09.2015 - 13:41
fuente
10

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

Ejemplo de cómo el código pequeño PUEDE ser: MenuetOS, un sistema operativo completo de 64 bits con aplicaciones potentes que caben en un solo disquete.

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

    
respondido por el Brian Knoblauch 24.09.2015 - 16:09
fuente
7

Es trivialmente cierto que el software debe construirse para que se ajuste 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. Bien duh Pero a medida que el hardware mejora básicamente en todas las dimensiones medibles, aumenta el número de programas discretos que se mueven de no aptos a ajustes: el espacio de diseño aumenta:

  • Los idiomas de nivel superior permiten expresar ideas en menos código y amp; 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 más fácil de usar al instante. Por ejemplo, probablemente no pasará mucho tiempo antes de que las aplicaciones de revisión ortográfica se incluyan con 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 elegir mejor el recurso que les interesa. Ver, por ejemplo, FLAC / OGG vs WAV, SVG vs PNG, índices de base de datos.
  • Las interfaces humanas a menudo intercambian lo que antes equivaldría a enormes cantidades de hardware para su uso. El suavizado, las altas resoluciones, la actualización rápida y el deslizamiento entre lo que equivale a paneles discretos hacen que la experiencia sea más realista, y por lo tanto intuitiva y fácil de relacionar.
respondido por el l0b0 24.09.2015 - 14:06
fuente
6

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

Cuanto más espacio haya 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 nuevas funcionalidades.

  • 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 sin pensar.

respondido por el Mike76 25.09.2015 - 09:03
fuente
4

Mucho de esto se reduce al tiempo del desarrollador y al costo de ese tiempo. En los días en que Visual Basic apareció por primera vez en la escena, estaba compitiendo con C / C ++ y el gran golpe en contra fue que se podía 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 en tiempo de ejecución de 300K.

Ahora, podría aumentar 10 veces el tamaño de su programa de VB y aún sería solo unos pocos K más, pero 10 veces el tamaño de su programa de C / C ++ y está buscando un poco más de desarrollo.

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

    
respondido por el andyb 25.09.2015 - 06:54
fuente
2

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 agregar un nuevo código. Nuevo código significa nuevas vulnerabilidades para corregir. La reparación de nuevas vulnerabilidades puede agregar código o abrir puertas a nuevas vulnerabilidades.

Cada función agregada para satisfacer las necesidades de un usuario puede necesitar más potencia del procesador para la velocidad (todos nos quejamos de la velocidad de este o el 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.

    
respondido por el user167772 24.09.2015 - 10:11
fuente
0

Gran parte del tamaño proviene de bibliotecas integradas. Muchas aplicaciones en estos días se construyen utilizando un electrón que enlaza una gran cantidad con la aplicación. Si instala aplicaciones en Linux, normalmente 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.

    
respondido por el Qwertie 02.12.2017 - 10:34
fuente
-1

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 * puede 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 con Java, necesita tener instalado JRE (> 60MB).

Si el ejemplo de Java no es bueno, intente esto: si el software necesita iniciar sesión en un archivo, puede usar un módulo de registro que puede hacer registros en la base de datos, en la red y en algunas otras funciones, pero las funciones son Nunca utilizado en el proyecto.

    
respondido por el neoedmund 25.09.2015 - 08:40
fuente
-2
  

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

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

Borrar la memoria inmediatamente le quitaría al usuario los ciclos de la CPU y el ancho de banda de la memoria cuando es más probable que deseen que se muestren en la pantalla páginas web con gran capacidad de respuesta.

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

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

    
respondido por el Phil Hannent 24.09.2015 - 16:49
fuente
-2

Puede ser cierto que los programas tienden a expandirse para llenar el espacio disponible, de manera similar a los fenómenos suburbanos en los que se agregan nuevos carriles a una autopista interconectada y en pocos años se realiza una copia de respaldo del tráfico.

Pero si lo investigas, es posible que los programas realmente hagan más cosas. Los navegadores, por ejemplo, ejecutan gráficos más sofisticados, tienen herramientas de desarrollador sofisticadas que no existían hace algunos años, etc. También se vinculan a muchas bibliotecas, a veces utilizando solo una pequeña parte del código. Entonces, si bien los programas pueden aumentar de tamaño para llenar la memoria disponible, algunos de ellos pueden ser razones legítimas.

    
respondido por el Paul J Abernathy 28.09.2015 - 15:32
fuente
-3

Las bibliotecas creadas en objetos que no están optimizados requieren más memoria para cargar, instalar y más ciclos de computación para operar. El código del objeto es en su mayor parte inflable.

Solo recorra el código estándar de C ++ que se ejecuta para ver todas las llamadas de objetos assert () ed para asegurarse de que sean objetos válidos. Cuando diseña capa sobre capa de objetos que encapsulan objetos, las capas inferiores 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 tan simple.

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

    
respondido por el daemondave 25.09.2015 - 22:54
fuente

Lea otras preguntas en las etiquetas