现代软件能快吗？(2008)

2020-08-16 00:10:35

所罗门曾经说过，不要怀念过去的美好时光，这是明智的建议，但我确信他并不打算将其应用于软件膨胀。

我说的不仅仅是内存和兆赫的膨胀--我们的性能也不膨胀。而且看起来这两个几乎是齐头并进的。某个东西占用的内存越多，它的运行速度就越慢。

对于700 KB的PDF，Foxit使用8 MB内存，Adobe使用56 MB内存。

好吧，也许Foxit不能显示所有最新的3D JavaScript增强的PDF，但它可以满足您的所有需求，而且它(相对)小、快、轻。

也许它有助于(或阻碍)成为一名嵌入式程序员，并且知道您可以用32KB的代码、2KB的RAM和8 MHz的8位处理器做多少事情。有时我希望开发人员必须在古老的66 MHz486上编写代码。约束是优化之母，在42核奔腾IX、10TB RAM开发机器上运行“足够快”的优化之后，程序员通常会忘记优化。

当然，我承认现在RAM和时钟周期很便宜，我们不妨使用它们。但这一切肯定是有限度的。当我的(纯文本！)。编辑器运行得足够慢，所以我可以看到屏幕在更新，有些地方不对劲。

当Visual Studio第一次弹出一个简单的属性窗口需要整整2秒的时间时，一定是出了问题。

回到那些日子，当程序员关心他们在CGA水平回溯时间内可以向视频内存写入多少字符而不会产生回雪的时候，在286上运行时，我看不到屏幕更新。

我们现在拥有1000倍的计算能力，就用户体验而言，东西的运行速度比它使用的速度要慢。我们忍住了，因为他们增加了一两个我们喜欢的功能，而且“足够好”了。但这就是不对。

而且它不仅仅是我的文本编辑器和Visual Studio。当雷鸟刚推出时，它在我相当普通的硬件上速度太慢，以至于我根本无法使用它。而现在，在我的2 GHz双核电脑上，不管它是什么，它仍然很慢。我第一次点击“收件箱”，花了一秒钟半的时间才弹出消息。来吧，各位-你可以在那段时间内从软盘驱动器上加载一个Usenet线程！

不知何故，我们说服自己，Gmail的对话视图和反垃圾邮件功能让它值得一直忍受750毫秒的Ajax延迟。不，就是不对劲。

最近，我读了迈克尔·阿布拉什(Michael Abrash)的“图形编程黑皮书”(Graphics Programming Black Book)，他在第二章中对这一切有一些很有说服力的(尽管有挑衅性的)说法：

您会注意到，我列出的高性能汇编语言编程目标不包括诸如易维护性和开发速度等传统目标。对于开发和分发软件的个人和公司来说，这些确实是重要的考虑因素。另一方面，实际购买软件的人只关心软件的性能有多好，而不关心它是如何开发的，也不关心它是如何维护的。如今，开发人员将如此多的时间花在诸如代码可维护性和可重用性、源代码控制、开发环境的选择等公认的重要问题上，以至于他们经常忘记第一条规则：从用户的角度来看，性能是根本。

我的理论是，这将需要一个RMS风格的先知出现，从阿布拉什的书中拿出几页，编写他自己的即时GUI操作系统，唤醒大众对响应计算的喜悦，并眼睁睁地看着臃肿的行业崩溃。

这将是一个你可以打开电脑并立即使用的世界。在这个世界中，您最多等待半秒来加载大程序。您的屏幕甚至在KeyUp事件发送之前就会更新的世界。不会是乌托邦，但我还是很期待。

我们正在接受这类预言家的投稿。把你的简历或简历放在下面的评论里。：-)

可能是我爸爸第一个给了我消肿的爱。他教我用x86汇编语言编程，也教我用Forth-一种可以用大约2KB编写编译器的语言。很久以前，他为DOS编写了一个小的TSR文本编辑器，叫做PED(弹出编辑器)。可执行文件PED.COM是3559字节，它可以在从运行DOS的8086到运行Windows XP的奔腾IV的所有操作系统上运行。

如果你仍然对小代码感兴趣，那么试试这个由巴勃罗·里达(Pablo Reda)开发的系统：

所有代码都在TXT文件中，文本编辑器可能会让您或您的父亲感兴趣。FORTH是一种以色彩为灵感的游戏。都是免费的。

诺曼，谢谢你的链接。我期待着阅读尼克劳斯·沃斯的文章(明天)。虽然我承认读这本书有困难(那是西班牙语吗？)。氧化还原4网站。：-)。

是的，visual studio和gmail也是最让我恼火的程序之一。当我有时间的时候，在工作之外使用TextPad编辑器是一件很愉快的事情。不过，很难想象行业会发生什么变化。我认为，只要没有更好的编程和设计范例，行业就会继续生产缓慢和臃肿的程序。

Re西班牙语reda4.org站点：有该手册的英文版本。该软件确实值得安装和使用：)编译成ASM并生成小的可执行文件。

在我看来，当人们抱怨臃肿时，他们真正的意思是‘我不需要它，所以没有人需要它’。

本，你的TSR之所以能在XP下运行，归根结底是因为每个Windows拷贝都附带了大量的兼容性代码。对于我们这些不运行传统DOS应用程序的人来说，这是100%的膨胀。

我认为“给开发者提供慢而烂的机器，让他们写出更快的软件”的论点是无效的，原因有两个：第一，开发者在开发过程中编辑、编译和测试应用程序的次数越多，错误就会被更快地消除；第二，对于一些软件(特别是游戏)，如果计划的发布日期是两年后，开发者应该使用大多数人届时会拥有的那种硬件，这样他们就可以利用新的功能或速度。

我同意现在很多软件反应迟钝！绝对令人惊讶的是，许多软件商店甚至没有通过代码分析器来运行他们的应用程序来查找瓶颈。仅此一项就可以非常显著地提高许多软件应用程序的性能！如果没有其他问题，至少可以通过代码分析器运行您的应用程序。

我真的很感谢您关于在速度较慢的机器上运行应用程序的评论。大多数开发人员忘记了他们拥有真正强大的盒子。在这些箱子上跑得足够好还不够好。在300-500美元的系统上试试。这应该是足够好的衡量标准了。

说到这个，我记得在大学的时候，我们必须在汇编中创建某种图形驱动程序。我们都在我们的开发盒上工作，并且有足够好的性能。然而，教授在最后一刻对我们开了个好头，他决定用一个速度只有四分之一的盒子来测试我们的司机。简短地说，他告诉我们，我们的司机必须在一定的规格内行驶，包括较慢的方格速度，但大多数人都忽略了这一点。因此，那些走捷径、表现足够好的人受到了相当严重的打击。

不过，总的来说，我不认为可维护性和优化是相互排斥的。我们的语言和系统在这两个方面都做得很差。

您记得的CGA显示屏包含80*25个字形，每个字形有2个字节(字符和颜色各一个)，数据量高达4000字节。在具有10×12像素栅格的现代位图显示器中，每固定宽度字符每像素16位的相同数据屏幕占用480000字节。这只代表了桌面上所有像素的一小部分。现代显卡的内存带宽是计算机中所有设备中最高的，这是有原因的。

不过，我偶尔会怀念MS-DOS时代的简短文本编辑器和Turbo调试器：-)。

您无法控制所有应用程序程序员的美感，但是您可以针对某个非常流行的发行版进行易于安装的速度调整集合。让我们创建一个针对快捷性进行优化的Ubuntu混音。Zoombuntu：)

使用Ubuntu Server安装和Blackbox桌面，我可以将启动时间缩短到15秒，但它缺少很多让我的笔记本正常工作的小程序(比如无线管理器)。我觉得速度的关键在于感知而不是表现。我希望看到立即启动计算机或打开程序时的视觉反馈，即使它是在后台加载额外的组件。

感知也会以另一种方式影响体验。无论程序有多大，它的加载速度可能会非常快，但如果它在加载过程中消耗了所有的CPU和IO带宽，那么它看起来就会很慢。

效率、灵活性和复杂性。您可以针对这三个选项中的两个进行优化，但代价是牺牲其他选项的增长。因为效率和灵活性都是必需的，所以实现这一目标的唯一方法是开始解决复杂性问题：我如何编写足够通用的代码，使其可以有效地针对其他体系结构进行优化，同时将其“实例化”到特定的体系结构，并利用该系统的约束所允许的所有优化？如何最大限度地减少向现有解决方案添加新数据处理流(例如功能参数、I/O设备、计算设备)带来的痛苦？

您可以让您的系统运行得更快，并减少…的臃肿。将屏幕分辨率和颜色设置为最小(640x480x16色？)，取消或停止所有后台进程，或者更好的做法是，让您的程序直接访问硬件…。只要人们愿意购买新的硬件/软件，这样他们就可以即插即用他们的数码相机，浏览1000张1Mb的照片，并将一些照片发送到他们刚刚插入的彩色照片打印机，让他的文本处理器在他们写作时检查拼写/语法并提出建议，从Internet获得直接更新，在后台检查文件和电子邮件中的病毒，将磁盘压缩等等，我们就会有“缓慢”和“膨胀”，因为这需要层层间接的…。

应该可以设置QEMU或其他一些虚拟机，这样您就可以在本地编译应用程序，但可以在速度慢得多的机器上使用它。这让您两全其美：开发人员必须在非超级计算机上自己做饭，但他们可以进行快速编译和更多迭代。

微软在将Office移植到Macintosh上时做了正确的事情。他们在60 MHz601的原始Power Mac上测试了每一个版本。这主意不错。

丹，公平地说，DOS TSR仍然在XP下工作是一个臃肿的例子-我想我同意。啊，我同意TextPad：它又轻又快。遗憾的是它不是免费的，而且遗憾的是版本5不如版本4好。

是的，GUI程序有问题。然而，我不认为一个“少做”的口头禅就能解决这个问题。

大多数软件的简单问题是，所有的工作都在一个线程中完成，因此交互性必须等待正在进行的处理。或者更糟糕的是，当您执行特定操作(例如MS Word的应用程序模式文件保存对话框)时，程序的部分UI会变得无法使用。

这里真正的答案是转换到支持MT的代码，这样工作就可以在后台线程上完成，而前台UI线程永远不会被锁定。

我同意其他人的看法--将Foxit Reader与Adobe Reader8进行比较并不是一种票价比较，因为正如您在文章后面所说的那样，Adobe Reader的功能比Foxit多得多。因此，它会占用更多的磁盘空间是完全有道理的。但是磁盘空间很便宜。

但是，您关于性能和内存使用的评论被很好地采纳了，并且与给定应用程序的磁盘空间使用没有任何关系。其中一个磁盘可以很小，并且具有很大的内存占用-反之亦然。

为此，我建议您给自己买一份刚刚发布的Adobe Reader9，然后再进行比较。我想你会发现一款比它的前身…更快更智能的产品。

[…]。我写了一篇博客，内容是关于臃肿的软件，以及Foxit PDF阅读器比Adobe Reader好多少。但我用的是Adobe Reader8。小[…]。

请，它应该呈现一个pdf文件。Foxit可以用更少的资源做我需要的一切。

“我承认现在的RAM和时钟周期很便宜，我们不妨使用它们。”是的，让我们用硬件做一些有用的事情。