如果查看老式程序Netscape Navigator或Microsoft Word的早期版本，则这些程序的大小不到50 MB。现在，当我安装google chrome时，它是200 MB，而Slack的桌面版本是300 MB。我了解到一些规则，即程序将占用所有可用内存，而不管内存是多少，为什么？

为什么与10或15年前相比，当前程序的大小如此之大？这些程序没有执行更多的功能，并且看起来也没有太大不同。现在是什么资源ho？

评论

只有4倍大吗？考虑到现代浏览器的功能还真令人惊讶，
作为附带说明，我相信“一些规则，即程序将占用所有可用内存，无论内存多少，但为什么呢？”可能是指随机访问内存，而不是物理磁盘空间，至少这是我对它的解释。可能是错误的。
因此，您要说的是，一个曾经占用了10美元的硬盘空间的程序现在占用了大约30美分的硬盘空间？我觉得很难担心。
“这些程序并没有显着地执行更多的功能” –好人。只需看一下HTML 4规范和CSS 1规范即可（不用担心，我会等待-即使您阅读它们也不会花很长时间）。 Netscape 4甚至都无法正确实现这些功能。 Chrome支持的新的疯狂HTML和CSS数量可观。另外，它具有标签。并且每六周更新一次。
顺便说一句。 Netscape的时间是50 MB，但是据记录，它不仅包括Web浏览器，还包括邮件客户端和HTML编辑器，甚至还有其他东西。

#1 楼

“看起来非常不同”是一个感知问题。如今的图形必须在与以前完全不同的屏幕分辨率下看起来不错，其结果是，一个过去足以用作徽标的100x100图像现在看起来非常发粘。必须用相同的东西的1000x1000图像替换它，这是原来的100倍。 （我知道您可以使用矢量图形代替，但这只是强调了这一点-必须将矢量图形渲染代码添加到以前不需要的系统中，因此这只是一种增加尺寸的折衷方案到另一个。）

“不同地工作”同样是一个感知问题。如今的浏览器比1995年的浏览器执行更多的工作。（下雨天尝试用一台历史悠久的笔记本电脑上网冲浪-您会发现它几乎无法使用。）使用很多的浏览器并不多，使用可能完全不知道90当然，最重要的是，普遍的趋势是花费更少的时间来优化空间，而更多地用于引入新功能。对于每个人来说，这是更大，更快，更便宜的计算机的自然副作用。是的，有可能编写与1990年一样资源高效的程序，其结果将是惊人的快速和流畅。但这不再具有成本效益。您的浏览器可能需要十年才能完成，届时要求将会完全改变。人们过去常常非常注重效率来编程，因为去年缓慢的小型机器迫使他们这样做，其他所有人也都在这样做。一旦这种情况发生改变，程序成功的瓶颈就从完全能够运行转变为运行越来越多的闪亮事物，这就是我们现在所处的位置。

评论

现代浏览器应包括的具体示例包括：密码库，Unicode数据库，JavaScript运行时和优化的JIT编译器，视频编解码器，PDF渲染器，以及用于所有受支持的MIME类型的复杂渲染引擎和解析器。这的确增加了，但是与游戏浏览器不同，浏览器不需要大量的高分辨率资源。现代化的Firefox下载仅压缩40–50MB。

–阿蒙
15年9月24日在8:01
“结果将是惊人的快速和流畅”-听起来像一厢情愿。

–布朗博士
15年9月24日在10:08
@amon不要忘记，浏览器还包括其他类型的资源以及用于插件和其他功能的完整API。它们甚至带有调试工具（分析器，网络分析器，元素检查器，功能齐全的控制台，调试器等等）。浏览器越来越接近我们所能想象的整个操作系统。甚至还有正在进行的使用Web Assembly的讨论！ O.P.应该被它们在浏览器中塞入的大量垃圾所惊叹。

–伊斯梅尔·米格尔（Ismael Miguel）
15年9月24日在11:29
@IsmaelMiguel就Chrome操作系统而言，浏览器已经是一个完整的操作系统。 ;-P

– Ajedi32
15年9月24日在13:33
倾向于花费更少的时间来优化空间。编写代码时，我不会针对空间或速度进行优化。我为维护进行了优化。与快速变化或较小变化相比，使代码库易于更改更为重要。我可以预期，对于每一个关于程序速度的抱怨，我都会收到十个关于新功能的请求，零个请求来缩小它。

–user2023861
2015年9月24日14:03在

#2 楼

如果将Netscape Navigator与现代浏览器进行比较，则功能会有很大的不同。只需将HTML 3.2规范（当我进行打印预览时为51页）与当前的HTML规范（PDF版本为1155页）进行比较。大小增加了20倍。

Netscape Navigator没有DOM，也没有CSS！没有动态更改文档，没有JavaScript修改DOM或样式表。没有标签。没有音频或视频。现代浏览器是一个非常复杂的程序。

评论

是的，最近的浏览器执行动画，渐变，图像滤镜效果，JavaScript，2D图形（画布），带有WebGL的3D图形，音频生成，游戏手柄（！），视频解码，高级客户端存储，对等通信（WebRTC），地理位置，WebSocket，Web密码术，MIDI，访问麦克风/网络摄像头，通知等。

–ysdx
2015年9月24日10:40


添加更多的东西（DOM，CSS，Javascript）以拥有更多的空间（多显示器，分辨率大幅提高：计算机屏幕越来越大：1999年至2011年）-800x600与1920x1080与4k ... 8k及以上... 1080至4k是分辨率的四倍... 8k又是四倍。

–WernerCD
2015年9月24日13:00


@WernerCD拥有更大的屏幕并不需要更大的二进制文件。无论是在800x600还是2560x1440显示器上显示，一个64 x 64像素的32位图标在磁盘上都需要相同的空间。调整窗口大小不会改变二进制文件的大小。与显示器有关的是，当您开始做像素加倍之类的工作时，则需要更大的资源才能继续保持清晰。

– 8bittree
2015年9月24日14:07


@ 8bittree，可以对软件性能提出更高的要求。而且性能更高的代码可能更复杂（例如，使用Canvas的网站可能比使用SVG的网站需要更多的复杂性和代码）。但是，是的，您基本上是正确的。

– Paul Draper
2015年9月24日14:19在
虽然确实可以肯定的是，当前的HTML比HTML 3.2的功能要多得多，但该规范本身也更加详细，这为规范增加了大量内容。对我来说，比较HTML 3.2对EM元素的描述的长度（完整的8或9个字）与HTML 5规范中相同的长度，这比包含周围描述该元素的材料要多一些，适用范围及其预期用途。

–用户
2015年9月25日在9:31

#3 楼

原因之一是应用程序内打包的数据更大，因为它们具有更高的分辨率和质量。 Netscape时代的图标最大为32x32像素，最大深度为8位（可能只有4个），而现在它的大小可能约为64x64，它是带有透明色的真彩色，即32位深度。那是大16倍。而且空间是如此的便宜，以至于人们在生成PNG时甚至都不用去检查“压缩”选项。如今，已经有一些应用程序与视频中的“入门”演示文稿一起交付。每。即使您没有使用运行时环境的所有功能，也仍然必须将整个程序与您的应用程序打包。我们可以在我们的应用程序中使用它，并且我们已经开发出一种使用库的文化，以避免不断重复发明轮子。当然，一旦开始使用库，就会弹出几个问题，并且我们已经养成了对它们提供最宽松答案的习惯：


它将仅由我的一项功能使用吗？ -是。


如果只需要该库提供的全部功能的一小部分，是否值得包含另一个库？ -是。


是否值得再包含一个库，如果将其包含在内只能使我节省2天的工作时间呢？ -是。


仅仅因为我工资单上的不同程序员碰巧已经熟悉了不同的库而包含多个或多或少地达到相同目的的库是否值得？ -是。
（请注意，我只是在观察这些趋势，对于我是否同意这些趋势，我不作任何陈述。）值得一提的是，当试图在多个选择中决定使用哪个应用程序时，一些用户认为占用更多空间的应用程序将具有更多功能，图形更加精美等。
因此，总而言之，软件的行为是否像天然气？它会占用所有可用空间吗？从某种意义上说是可以的，但没有任何令人震惊的程度。如果我们看一下驱动器上占用最多空间的原因，那么对我们大多数人来说，答案是，到目前为止，它不是应用程序，而是电影和音乐等媒体。软件的膨胀速度并没有以存储容量的增长速度膨胀，而且软件膨胀的可能性也不大，因此将来，应用程序可能只占用户可用存储空间的很小一部分。

评论

这是正确的答案。 （目前）评分较高的评论提到了更多的功能，但这并不能完全解释增加的尺寸。大小来自提供这些功能的随附库。

–user1936
2015年9月24日在13:39
@IsmaelMiguel很好，我在谈论普通用户。另外，游戏是一种特殊情况，因为这35GB的大部分内容是媒体，而不是代码或库。碰巧是只能通过特殊应用程序（即游戏）查看的媒体。但是，即使对于游戏玩家而言，今天的数TB的驱动器上也没有35GB的存储空间。不管怎样，假设如果您是一个坚持拥有小型硬盘的游戏玩家，那么您就远不代表那里的用户。

–迈克·纳基斯（Mike Nakis）
2015年9月24日15:08


@MikeNakis并非每个游戏者都有1TB驱动器，或者有钱购买256GB SSD。像我这样的一些人拥有128GB的SSD，或者笔记本电脑的容量不足500GB。前一段时间，我80％的SSD空间使用只是游戏。仅仅进行了3-4场比赛，就占据了整个空间。在游戏本身中，几乎每个人都拥有一台笔记本电脑并在上面玩游戏。

–伊斯梅尔·米格尔（Ismael Miguel）
2015年9月24日15:19


@Mike哦，没关系。当我们说应用程序的大小时，我们指的是可下载安装文件的大小，或者安装后该应用程序在磁盘上所占的总空间。这包括库，媒体，数据以及所有内容。如今，为了避免不兼容的问题，应用程序通常与它们所需的大多数库一起提供，而不是希望这些库已经安装并且版本正确，等等。主可执行文件的大小确实没有任何意义，也没有任何后果。

–迈克·纳基斯（Mike Nakis）
15/09/24在23:24


@IsmaelMiguel对于程序员而言，很可能是他们不同的虚拟机，Docker容器等。没有比完整的肿系统好得多的膨胀；-)

–cmaster-恢复莫妮卡
2015年9月25日在21:27

#4 楼

除了其他答案之外，十年前，本地化/国际化版本通常会有单独的版本。现在，通常情况下，程序会将完全的本地化支持捆绑到每个发行的版本中，从而扩大了程序的大小。

评论

我可能是错的，但是我正在幻想字符串是该问题的最基本部分。确实，那里有很多语言，但是用户看到的字符串数量仍然非常有限。毕竟，在用户界面上失败的最可靠方法之一就是包含过多的文本。

–cmaster-恢复莫妮卡
2015年9月25日在21:30
除了@cmaster所说的那样，Firefox专门不捆绑完整的本地化（在我考虑的同时，OpenOffice也没有）。

– BenjiWiebe
2015年9月26日，下午1:41
@cmaster字符串，不。但是本地化的视频和音频，尤其是在游戏环境中？ IIRC有一个60 GB的游戏（GTA V？），其中> 10 GB只是本地化的音频。这是一个很大的块。

–鲍勃
15年9月27日在23:30
@Bob是的，我不是在考虑游戏，它们似乎是我写的一个大例外。

–cmaster-恢复莫妮卡
2015年9月28日下午5:16
对于每种语言，字符串表可能总计多达几个额外的K字节。仅应用程序图标本身通常会使所有字符串内容的总大小相形见（（可能是带有嵌入式词典的应用程序除外）

– andyb
2015年10月3日在18:06

#5 楼

原因之一是依赖关系。一个具有丰富功能和外观的程序需要完成许多工作-加密，拼写检查，使用XML和JSON，文本编辑以及许多其他工作。他们从哪里来？也许您自己滚动，并使其尽可能小。您很可能会使用第三方组件（也许是MIT许可的开放源代码），而这些组件实际上并不需要很多功能，但是一旦您需要第三方组件中的一个功能，则通常必须携带整个组件。因此，您添加了越来越多的依赖项，并且随着它们自身的发展和增长，依赖于它们的程序也随之增长。

评论

我很好奇为什么这会在一夜之间得到两票。

–锋利的牙齿
2015年9月25日在7:46
我没有，但是我认为这不能真正深入地回答问题。它几乎只是说“软件变得更大，因为它可以做更多的事情”，您会从其他答案中看到，它的确包含了更多的内容。

–轨道轻赛
2015年9月25日在11:32
一个相关的因素是，在使用静态链接的系统中，链接器可能只需要提取实际使用的代码即可（某些链接器总是会提取所有内容，而更好的链接器则是选择性的）。使用动态链接时，尤其是可以共享模块的情况下，即使安装模块的第一个代码仅需要一个功能，也无法知道要共享模块的其他代码可能需要哪些功能。

–超级猫
2015年9月25日在17:09
@sharptooth我什至不知道了。虽然在大多数情况下该系统都能正常工作，但我也看到可怕的错误答案被疯狂地接受和接受，而正确的错误答案却常常被人们遗忘...

–布赖恩·诺伯劳赫（Brian Knoblauch）
2015年10月2日，14：11

#6 楼

尽管图形/可用性确实是影响因素，但其中有很多是库/多余的编译代码。

代码仍然可以很小的示例：MenuetOS，功能强大的完整64位OS适用于单个软盘的应用程序。

没有明显原因的大代码示例：我做了一个简单的文本输出“ Hello，World！”。最近在阿达编译的可执行文件超过1 MiB!。汇编中的同一可执行文件只是KiB或2（并且大部分是可执行文件的开销，实际运行的代码是数十个字节）。

评论

什么是软盘？ ;）

– 500-内部服务器错误
15年9月24日在19:42
@ 500-InternalServerError什么是Ada？ ：D

– BenjiWiebe
15-09-26在1:42


对于新手，软盘约为1.4 MiB

–显示名称
2015年9月26日在7:51
我已经看到200字节以下的现代Ada可执行文件。但是，如果您的编译器在默认情况下引入了诸如完整任务运行时之类的功能，则无论您是否使用任务，都将需要1MB左右。而且通常不值得将其剥离。

–布赖恩·德拉蒙德（Brian Drummond）
2015年9月26日17:13


@BrianDrummond，听起来像是一个糟糕的运行时，或者糟糕的运行时以及库和链接器。在我多年前看到的培训视频中，Jean Ichbiah等人提到典型的Ada运行时（对于该语言的原始版本）约为4K。出于好奇，我对照我们使用的TI 320C30运行时软件包对此进行了检查。他的钱是对的。

– John R. Strohm
16 Mar 10 '16 at 21:05

#7 楼

毫无疑问，必须将软件构建为适合两件事：用户和可用的硬件。如果程序可以及时地执行用户想要的操作，并且硬件可供用户使用，则该程序适合其目的。好吧但是随着硬件在所有可测量维度上的改善，从不合适到适合的离散程序的数量增加了-设计空间越来越大：用比以前更少的代码和时间来表达想法。相反，这种降低的复杂性使得表达日益复杂的想法成为可能。

将更多数据与应用程序捆绑在一起可以使其立即变得更有用。例如，拼写检查应用程序与人类已知的每种语言捆绑在一起的时间可能不会很快-毕竟只有几千兆字节。他们关心哪些资源。例如，参见FLAC / OGG与WAV，SVG与PNG，数据库索引。

Humane接口通常会折衷使用以前需要大量硬件才能实现的可用性。抗锯齿，高分辨率，快速刷新以及在不连续面板之间进行滑动都可以带来更逼真的，因此直观且相关的体验。


#8 楼

关于Android应用程序，这绝对是正确的。四年前，一个简单的应用程序占用了大约2-5兆字节的空间。
如今，一个简单的应用程序需要约10-20兆字节的空间。

可用空间越多，应用程序大小就越大。

我认为主要有两个使用Android的原因：


Google扩展了Android框架，添加了许多新功能。
开发人员不再关心。图像包含在更高的分辨率中（当然，智能手机的屏幕分辨率有所提高），而第三方库则被包含在内。

评论

最后一点是正确的。

–轨道轻赛
2015年9月25日在11:32
我总共制作了一个Android应用，APK为0.05MB。再说一次，它没有做太多。我仍然想知道为什么一个秒表应用程序（功能与我的类似，尽管完全不同）却需要几个MB。

–user253751
15/09/26在12:15


最后一个要点是错误的，开发人员会注意。我们只需要考虑各种优先事项，然后将该应用程序做得更大一点就可以了。

–NPSF3000
2015年9月26日23:35
SDK当时坚持要在我不需要的0.05MB应用程序中添加5MB以上的库，这也无济于事，我还记得在发布版本之前将其删除。

–user253751
18年7月24日在0:41


#9 楼

其中很多都归结为开发人员的时间和时间的成本。早在Visual Basic首次出现时，它就与C / C ++竞争，最大的障碍是您可以用ANSI C for Windows编写“ Hello World”（大约15K）。 VB的问题是，您总是遇到300K运行时库的问题。

现在，您可以将VB程序的大小增加10倍，仍然只有几千个K，但是将C / C ++程序的大小增加十倍，并且您需要再查看MONTHS发展。

最后，您的应用程序膨胀是一笔小钱，可以弥补开发生产的巨大飞跃，价格降低和功能的巨大变化，而这是旧手工制作无法实现的发展的日子；当程序小而又快但又很弱，彼此不兼容，功能不足且开发成本高时。

评论

这篇文章很难阅读（文字墙）。您介意将其编辑为更好的形状吗？

– gna
2015年9月25日在7:18
Hello World的“ 10倍大小”需要“数月的发展”吗？十次刷牙是否需要不停地站在镜子前一个月？

–律师
15年9月29日在6:50
x刷牙x是x的线性函数，但是编程通常不是线性函数。如果您使用最底层的语言功能手工编写每一行代码，您将获得快速而小的代码，但是每级别的复杂性成本更高。高级语言的膨胀更多，但使成本更接近复杂性的线性函数。

– andyb
2015年10月3日17:59


#10 楼

随着时间的流逝，用户的需求在不断发展，并且需求也越来越大，因此，不同软件的供应商/作者被迫以竞争的名义满足这些需求。

但是满足新的需求意味着经常添加新的代码。新代码意味着需要修复的新漏洞。修复新漏洞可能会添加代码或为新漏洞打开大门。

满足用户需求的每个新增功能可能都需要更多处理器能力来提高速度（我们都抱怨这种浏览器的速度）新的图形资源以获得更好的视觉效果...等。所有这一切都意味着增加了应用程序（代码），安全性以及有时是硬件的新层。

#11 楼

许多大小来自内置库。如今，许多应用是使用电子构建的，电子与应用捆绑在一起。如果您在Linux上安装应用程序，它们通常会小得多，因为许多应用程序已经通过其他程序也在使用的共享库进行了安装。

#12 楼

构造软件时，如果需要功能A，则将导入模块A *。 A *可以解决A，但是A *比A可以解决更多的问题，而且A *可能很大。所有大型模块都会生成大型软件。

情况可能不一样，但类似这样：如果只需要使用Java在控制台上打印“ hello world”，则需要JRE（ > 60MB）。

如果Java示例不好，请尝试以下一种方法：如果该软件需要记录到文件，则可以使用一个记录模块，该模块实际上可以通过数据库记录日志网络和其他一些功能，但是这些功能从未在项目中使用过。

评论

为什么确切地说有5个否决票，而没有一个评论解释原因？

– Kromster
2015年9月26日在17:54
@KromStern第一部分极大地掩盖了库的工作方式，并且在代码使用不一致的情况下以非常不清楚的方式进行了工作。我认为它根本无法真正回答问题。第二部分以Java为例（尽管试图宣称JRE应该被认为是应用程序规模增长的一部分-再次遗漏了问题的要点，这根本不是一个公平的示例，并且将使JRE永存。 Java的误解）。总而言之，这要么是错误的，要么是重复以前写得更好的答案。

–user40980
2015年9月27日在1:04
您记录到网络或文件的示例也不是一个好例子-因为从代码的角度来看，两者都是文件，并且处理方式完全相同（文件和网络之间的区别由操作系统处理）。我还没有看到一个将“登录数据库”作为其核心功能的一部分的日志记录框架，因为Oracle，MySQL，Sql Server，Postgres，...驱动程序和辩证法的区别会使其变得复杂。

–user40980
15年9月28日在13:46
@ user40980操作系统无法处理文件和网络之间的区别。他们需要不同的OS调用才能进行连接和写入。数据库访问通过诸如JDBC或libdbi之类的数据库独立层进行处理。 （进而可能会为所有不同的受支持数据库引入驱动程序！）

–user253751
18年7月24日在0:46


#13 楼


我读到一些规则，即程序将不占用所有可用内存
有多少，但为什么呢？在操作系统承受内存压力之前，系统不会释放已消耗的内存。这是一项性能改进。如果您正在浏览带有图像的页面，则可以离开。您可能会向后导航，因此再次需要该图像。如果操作系统具有RAM，则除非确定您不再需要它，否则没有必要清除内存。

操作系统可能会消耗所有可用的非应用程序内存，其中大部分用于文件系统缓存。

内存管理是一个难题，但一直有很多聪明的人在忙于解决。没有任何事情是故意浪费的，关键目标是为您提供响应速度快的计算机。

评论

那根本不是那句话。在写引号时才发明了虚拟内存和垃圾回收，并且它们并不普及。

–Jörg W Mittag
15年9月24日在22:40

#14 楼

的确，程序趋向于扩展以填充可用空间，这与郊区现象类似，在郊区现象中，您将新车道添加到拥堵的高速公路，并在几年之内再次备份了流量。调查一下，您可能会发现他们的程序实际上在做更多的事情。例如，浏览器运行更高级的图形，拥有几年前不存在的漂亮的开发人员工具等。它们还链接到许多库，有时仅使用一小部分代码。因此，尽管程序可能会增加大小以填充可用内存，但其中某些原因可能是出于正当的理由。

评论

在前面的13个答案中，这似乎并没有提供任何实质性的解释。

– gna
15年9月28日在21:41

#15 楼

在未优化的对象上构建的库需要更多的内存来加载，安装和运行更多的计算周期。目标代码大部分是膨胀的。

只需逐步运行标准C ++代码即可查看所有assert（）ed对象调用，以确保它们是有效的对象。当您一层又一层地设计对象来封装对象时，底层会变得blo肿且不透明。程序员会变得懒惰并承担更多的对象，因为它比重新设计受限于所需功能的对象要快。真的就是这么简单。

考虑Linux C内核的大小（仅内核）与定制应用程序的大小。内核可以运行整个机器。但是它的构建速度不如应用程序快，它需要花费一些时间才能实现最佳功能。