web应用程序和编译应用程序在资源分配和效率方面是否存在差异？

Question

我是个网络开发者。我觉得我经常开发更少的资源密集型功能，因为我有这样的感觉，如果我对web应用程序(动画、计算、连接等)要求过高，对于计算机速度较慢的用户来说，它就会滞后。

一段时间以来，我一直好奇web (解释)应用程序与编译应用程序的能力(资源分配)有多大的不同。

另外，我听说与编译的程序(例如，C++)相比，解释程序(例如JS)效率很低，而且需要资源。谷歌的V8 JS引擎据说使JS速度更快，但我仍然看到人们谈论JS比C++效率低得多。

我提出这个问题的原因是要把事实与偏见分开。

• web应用程序和编译应用程序在可用CPU和RAM方面是否存在差异？
• 用(解释语言) JS编写的程序与用(编译语言) C++编写的程序之间有很大的效率差异吗？

编辑:我知道我们在比较苹果和橘子。在开发客户端应用程序时，在C++ (任何编译的东西)和JavaScript (web)之间有一些非常明确的选择，这是决定的一个方面，如果它在我的职业生涯中出现的话，我不想被误导。

Answer 1

web应用程序和编译应用程序在可用CPU和RAM方面是否存在差异？

您的web应用程序运行在浏览器的上下文和它的扩展，浏览器需要一些内存和CPU周期的家务。因此，应用程序无法使用该内存和这些周期。在满载的桌面上，相对于可用的周期和内存，浏览器维护所需的CPU周期或内存的比例很小。在低端智能手机上，它可能会产生更大的影响。

用(解释语言) JS编写的程序与用(编译语言) C++编写的程序之间有很大的效率差异吗？

在JavaScript解释器或其他VM中运行的程序将具有编译语言所不需要的一些开销。在某些情况下，这种开销很大，而在其他情况下，它可能允许进行优化，从而使解释的程序比编译的程序更快。这取决于你想要解决的问题。

问自己以下问题：

我需要不受限制地访问机器的硬件吗？

我需要用我自己设计的自定义行为替换OS或语言运行时库的功能吗？例如，是否需要关闭标准内存分配系统并实现自己的内存分配系统？

如果不使用系统容量的最后一点和标题，我运行的计算是否如此复杂，以致于很难及时完成它？考虑一下比特币的挖掘、蛋白质折叠模拟或实时过程控制。

如果您回答这些问题中的任何一个，您可能需要使用程序集、C、C++或其他一些系统编程语言。

有些任务，比如渲染流媒体视频，在计算上非常复杂，但每个人都需要它们，所以编写浏览器的C和C++程序员将它们包装成库，由HTML5或JavaScript调用。从JavaScript或通过HTML5标记调用这些库比从C++程序调用这些库的效率还要低。

计算机不会感到无聊或疲劳，因此担心效率本身是没有意义的。只有当程序的性能限制无法满足时，它才会成为关注的焦点。早在1987年，只要安装几个窗口、按钮和可伸缩字体，CPU所能提供的每一个周期都是必需的，所以编译语言是城里唯一的游戏。现在，如果你的程序的主要工作是和一个人交互--拖动窗口和点击按钮--你的电脑将花费大部分时间来旋转它的比喻拇指，而其他的问题，比如开发时间，就变得更加重要了。

Answer 2

也许描述web开发人员区别的最简单的方法是突出asm.js和Google的本地客户端。

如果javascript web应用程序的速度几乎和C++这样的编译语言一样快，那么没有人会试图让web应用变得如此快，事实表明，这两个系统在性能和效率上存在差异。

Javascript编译器现在非常好，但它们仍然滞后于本机代码。问题的一部分是javascript的“表现性”语法，这也是asm.js被发明的原因--它是javascript的一个非常特定的子集，它的限制要大得多，但这使得编译成高效的代码更加容易，从而使它能够更好地执行。然而，它仍然比本机代码慢，但一些基准测试显示“只”慢了两倍，而其他基准测试则说普通javascript的运行速度只有原来的两倍。基准，哈！

本机客户端采用了不同的策略，提供了一个沙箱环境来运行真正的本地编译代码。它并没有像javascript那样集成到浏览器环境中，但这主要是因为它的吸收和建立的环境是怎样的，而不是它们可能是什么。

Answer 3

目前的Javascript翻译非常非常快，就像口译员一样。没有多少可用的“好”基准，这个似乎是最不值得怀疑的- -javascript C++显示Javascript的长度仅是同一计算密集型基准的C++的两倍，这对于解释语言来说是惊人的好。

虽然就性能而言，没有什么能胜过编码良好的C，但缺点是巨大的：-

• 更长的开发周期
• 内置的文本处理很差
• 没有内置的“集合”(C++有boost/templates等)
• 每个支持的平台所需的构建(通常是代码更改)。
• 在运行之前，您需要分发和安装
• 您需要永远支持旧版本，或者找到某种方式迫使用户升级。
• 您的应用程序将本地运行，引发一系列安全问题。