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

186

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?

Niklas Rosencrantz
fuente
134
¿Solo 4 veces el tamaño? Eso es increíble considerando cuánto más hace un navegador moderno
Richard Tingle
23
Como nota al margen, creo 'alguna regla de que los programas tomarán toda la memoria disponible, no importa cuánto sea, pero ¿por qué?' probablemente se refiere a la memoria de acceso aleatorio en lugar de espacio físico en el disco, al menos esa sería mi interpretación de ella. Podría estar equivocado
Trotski94
103
Entonces, ¿lo que está diciendo es que un programa que alguna vez ocupó $ 10 de espacio en el disco duro ahora ocupa alrededor de 30 centavos de espacio en el disco duro? Me resulta difícil preocuparme por esto.
Eric Lippert
49
"Los programas no están haciendo muchas más funciones" - buen señor. Solo eche un vistazo a la especificación HTML 4 y la especificación CSS 1 (no se preocupe, esperaré, no le tomará mucho tiempo incluso si las lee). Netscape 4 ni siquiera logró implementarlos correctamente. Solo la cantidad de HTML y CSS nuevos y locos que Chrome admite es considerable. Además tiene pestañas. Y se actualiza cada seis semanas.
Paul D. Waite
13
Por cierto. 50 MB en tiempos de Netscape era grande, pero, para el registro, incluía no solo el navegador web sino también el cliente de correo y el editor HTML, y tal vez incluso algo más.
el.pescado

Respuestas:

266

"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.

Kilian Foth
fuente
120
Ejemplos concretos de cosas que un navegador moderno debería incluir serían bibliotecas criptográficas, la base de datos Unicode, un tiempo de ejecución de JavaScript y un compilador JIT optimizador, códecs de video, un renderizador de PDF, además de un complicado motor de renderizado y analizadores para todos los tipos MIME compatibles. Eso suma, pero a diferencia de los navegadores de juegos no requieren muchos activos de alta resolución. Una descarga moderna de Firefox solo pesa entre 40 y 50 MB comprimidos.
amon
23
"El resultado sería asombrosamente rápido y resbaladizo", parece una ilusión.
Doc Brown
16
@amon No olvide que los navegadores también incluyen otro tipo de recursos y una API completa para complementos y demás. Incluso vienen con herramientas de depuración (perfiladores, analizadores de red, inspectores de elementos, una consola totalmente funcional, depuradores y mucho más). Los navegadores se están acercando a un sistema operativo completo de lo que todos podemos imaginar. ¡Incluso hay una discusión en curso para usar Web Assembly! El OP debería estar sorprendido por la tonelada de basura que pueden acumular en un navegador.
Ismael Miguel
10
@IsmaelMiguel En lo que respecta a Chrome OS, los navegadores ya son un sistema operativo completo. ;-P
Ajedi32
111
tendency to spend less time on optimizing things for space Esta. Cuando escribo código, no optimizo el espacio o la velocidad. Optimizo para mantenimiento. Es más importante que la base de código pueda cambiar fácilmente que ser rápida o pequeña. Puedo esperar que por cada queja sobre la velocidad del programa, reciba diez solicitudes de nuevas funciones y cero solicitudes para hacerlo más pequeño.
user2023861
109

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.

JacquesB
fuente
12
Sí, los navegadores recientes hacen animaciones, degradados, efectos de filtros de imagen, JavaScript, gráficos 2D (lienzo), gráficos 3D con WebGL, generación de audio, Gamepad (!), Decodificación de video, almacenamiento avanzado del lado del cliente, comunicación entre pares (WebRTC), Geolocalización, WebSocket, WebCryptography, MIDI, acceso a micrófono / cámara web, notificaciones, etc.
ysdx
1
Agregue hacer más cosas (DOM, CSS, Javascript) a tener también más bienes raíces (Monitores múltiples, aumento masivo de resolución: Pantallas de computadora cada vez más grandes: 1999 a 2011 ) - 800x600 vs 1920x1080 vs 4k ... 8k y más ... 1080 a 4k es cuádruple la resolución ... 8k es cuádruple nuevamente.
WernerCD
77
@WernerCD Simplemente tener una pantalla más grande no requiere un binario más grande. Un icono de 64 por 64 píxeles y 32 bits requerirá la misma cantidad de espacio en el disco, ya sea que se muestre en un monitor de 800x600 o 2560x1440. Cambiar el tamaño de su ventana no cambia el tamaño del binario. Lo que importa con las pantallas es que cuando comienzas a hacer cosas como duplicar píxeles, entonces necesitas mayores recursos para seguir viéndolo bien.
8bittree
1
@ 8bittree, puede aumentar la demanda del rendimiento del software. Y un código más eficaz puede ser más complejo (por ejemplo, un sitio web que usa Canvas probablemente necesita más complejidad y código que uno que usa SVG). Pero sí, en su mayoría tienes razón.
Paul Draper
1
Si bien es cierto que el HTML actual hace mucho más que HTML 3.2, la especificación en sí también es mucho más detallada, lo que agrega una cantidad significativa de contenido a la especificación. Compare la longitud de la descripción del EMelemento en HTML 3.2, un total de ocho o nueve palabras, con la longitud de la misma en la especificación HTML 5 , para mí, más que una pantalla que incluye el material circundante que describe el elemento, donde es aplicable y cuál es su uso previsto.
un CVn
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. 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.

Mike Nakis
fuente
17
Esta es la respuesta correcta. Los comentarios (actualmente) de mayor calificación mencionan más funcionalidad, pero eso no explica completamente el aumento de tamaño. El tamaño proviene de las bibliotecas incluidas que proporcionan esas funcionalidades.
user1936
55
@IsmaelMiguel bueno, estaba hablando de usuarios habituales. Además, los juegos son un caso especial, porque estos 35 GB son en su mayoría medios, no código, ni bibliotecas. Resulta que son medios que solo puedes ver a través de una aplicación especial, que es el juego. Pero incluso para un jugador, 35 GB no son nada en las unidades de varios terabytes actuales. De todos modos, suponga que si usted es un jugador que insiste en tener una unidad pequeña, entonces no está cerca de ser un representante de los usuarios.
Mike Nakis
2
@MikeNakis No todos los jugadores tienen una unidad de 1 TB o el dinero para comprar una SSD de 256 GB. Algunos, como yo, tienen una SSD de 128 GB o una computadora portátil con menos de 500 GB. Hace un tiempo, el 80% de mi uso de espacio SSD eran simplemente juegos. Fue simplemente 3-4 juegos, comiendo el espacio. Y en el juego en sí, casi todos tienen una computadora portátil y juegan en ella.
Ismael Miguel
55
@ Mike, oh, no importa. Cuando hablamos del tamaño de una aplicación, nos referimos al tamaño del archivo de instalación descargable o al espacio total ocupado por la aplicación en el disco una vez instalado. Esto incluye bibliotecas, medios, datos, todo. Y hoy en día, para evitar problemas de incompatibilidad, las aplicaciones generalmente se envían junto con la mayoría de las bibliotecas que necesitan, en lugar de esperar que las bibliotecas ya estén instaladas y tengan la versión correcta, etc. El tamaño del archivo ejecutable principal no realmente de ningún interés, ni de ninguna consecuencia.
Mike Nakis
3
@IsmaelMiguel Para un programador, es probable que sean sus diferentes máquinas virtuales, contenedores acoplables y demás. No hay mejor hinchazón que multiplicar sistemas hinchados enteros ;-)
cmaster
16

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.

Eterm
fuente
55
Puedo estar equivocado, pero estoy trabajando bajo la ilusión de que las cuerdas son la menor parte de este problema. Es cierto que hay muchos idiomas, pero la cantidad de cadenas que un usuario ve es muy limitada. Después de todo, una de las formas más seguras de fallar en su interfaz de usuario es incluir demasiado texto.
cmaster
55
Agregando a lo @cmaster Dicho esto, Firefox específicamente qué no bundle localización completa (y mientras yo estoy pensando en ello, tampoco lo hace OpenOffice.)
BenjiWiebe
2
@cmaster Strings, no. ¿Pero el video y el audio localizados, especialmente en el contexto de los juegos? IIRC había un juego de 60 GB (¿GTA V?) Donde> 10 GB era solo audio localizado. Esa es una parte significativa.
Bob
@Bob Correcto, no estaba pensando en los juegos, parecen ser la gran excepción a lo que escribí.
cmaster
Para cada idioma, la tabla de cadenas puede agregar algunos K bytes adicionales. Sólo los iconos de aplicaciones normalmente solo enano del tamaño total de todo el contenido de cadena (posibles excepciones de aplicaciones con los diccionarios integrados)
andyb
13

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.

diente filoso
fuente
Tengo curiosidad de por qué esto recibió dos votos negativos durante la noche.
Sharptooth
66
No lo hice pero no creo que esto realmente responda la pregunta con suficiente profundidad. Simplemente dice "el software se hace más grande porque hace más cosas", y verás en las otras respuestas que realmente hay más que eso.
ligereza corre en órbita el
1
Un factor relacionado es que en los sistemas que usan enlaces estáticos, un enlazador solo necesita introducir el código que realmente se usa [algunos enlazadores siempre tirarían de todo, pero los mejores intentaron ser selectivos]. Cuando se utiliza la vinculación dinámica, especialmente si los módulos se pueden compartir, incluso si el primer código que instala un módulo solo necesita una función, no hay forma de saber qué funciones puede necesitar otro código que quiera compartir el módulo.
supercat
@sharptooth Ya ni siquiera me pregunto. Si bien en la mayoría de los casos el sistema funciona, también veo que las respuestas rotas horriblemente incorrectas se votan como locas y aceptadas, mientras que las correctas se rechazan al olvido con demasiada frecuencia ...
Brian Knoblauch
10

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).

Brian Knoblauch
fuente
3
¿Qué es un disquete? ;)
500 - Error interno del servidor
@ 500-InternalServerError ¿Qué es Ada? : D
BenjiWiebe
3
para los recién llegados, el disquete es de aproximadamente 1.4 MiB
Sarge Borsch
3
He visto ejecutables Ada modernos con menos de 200 bytes. Pero si su compilador utiliza cosas como un tiempo de ejecución de tareas completo de manera predeterminada, ya sea que use tareas o no, entonces es de esperar 1 MB o menos. Y generalmente no vale la pena molestarse en quitarlo.
Brian Drummond
@BrianDrummond, suena como un tiempo de ejecución realmente malo, o un tiempo de ejecución y biblioteca y enlazador de mala calidad. En un video de capacitación que vi hace muchos años, Jean Ichbiah et al mencionaron que un tiempo de ejecución típico de Ada (para la versión original del lenguaje) sería de aproximadamente 4K. Por curiosidad, verifiqué esto con el paquete de tiempo de ejecución TI 320C30 que estábamos usando. Tenía razón en el dinero.
John R. Strohm
7

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.
l0b0
fuente
6

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.

Mike76
fuente
1
Ese último punto es exactamente correcto.
ligereza corre en órbita el
3
Hice un total de una aplicación de Android, y el APK es de 0.05MB. Por otra parte, no hace mucho. Todavía me pregunto por qué una aplicación de cronómetro (con una cantidad de funcionalidad similar a la mía, aunque completamente diferente) toma varios MB.
immibis
55
El último punto es incorrecto, a los desarrolladores les importa. Solo tenemos que hacer malabares con varias prioridades y hacer que esa aplicación sea un poco más grande tiene sentido.
NPSF3000
Tampoco ayudó que el SDK (en ese momento) insistiera en agregar una biblioteca de más de 5 MB a mi aplicación de 0.05 MB que no necesitaba, y tuve que recordar eliminarlo antes de una versión de lanzamiento.
immibis
4

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.

andyb
fuente
2
esta publicación es bastante difícil de leer (muro de texto). ¿Te importaría editarlo en una mejor forma?
mosquito
1
¿"10 veces el tamaño" de Hello World requiere "meses más de desarrollo"? ¿Cepillarse los dientes diez veces implica estar parado frente a un espejo sin parar durante un mes?
bcrist
Cepillarse los dientes x veces es una función lineal de x, pero la programación generalmente no es una función lineal. Si crea artesanalmente cada línea de código utilizando las funciones de lenguaje de nivel más bajo, obtiene un código rápido y pequeño pero a un costo más alto por nivel de complejidad. Los idiomas de nivel superior se hinchan más pero mantienen el costo más cerca de una función lineal de la complejidad.
Andy
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 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.


fuente
0

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.

Qwertie
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 * 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.

neoedmund
fuente
¿Por qué exactamente hay 5 votos a favor y ningún comentario explicando por qué?
Kromster
1
@KromStern La primera sección pasa por alto en gran medida cómo funcionan las bibliotecas, y lo hace de una manera muy poco clara con un uso inconsistente de code. Yo diría que en realidad no responde a la pregunta en absoluto. La segunda sección usa Java como ejemplo (aunque intenta afirmar que el JRE debe considerarse parte del crecimiento del tamaño de la aplicación, lo que nuevamente pierde el punto de la pregunta y no es un ejemplo justo en absoluto y continúa perpetuando el malentendidos de Java). En general, está mal o repite puntos en respuestas anteriores, mejor escritas.
1
Su ejemplo de iniciar sesión en la red o el archivo tampoco es bueno, porque desde el punto de vista del código, ambos son archivos y se manejan exactamente de la misma manera (el sistema operativo maneja la distinción entre archivo y red). Todavía no he visto un marco de registro que tenga "iniciar sesión en la base de datos" como parte de su funcionalidad principal, ya que esto sería complicado por Oracle vs MySQL vs Sql Server vs Postgres vs ... controladores y diferencias dialécticas.
@ user40980 La distinción entre el archivo y la red no es manejada por el sistema operativo. Necesitan diferentes llamadas al sistema operativo para conectarse y escribir. El acceso a la base de datos se maneja a través de una capa de independencia de la base de datos como JDBC o libdbi. (¡Lo que a su vez puede atraer controladores para todas las diferentes bases de datos compatibles!)
immibis
-2

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.

Phil Hannent
fuente
3
De eso no se trata en absoluto ese dicho. La memoria virtual y la recolección de basura acababan de inventarse cuando se escribió esa cita, y no estaban muy extendidos.
Jörg W Mittag
-2

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.

Paul J Abernathy
fuente
2
Esto no parece ofrecer nada sustancial sobre los puntos hechos y explicados en 13 respuestas anteriores
mosquito
-3

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.

daemondave
fuente