推动 JavaScript 性能的限制是什么？答案

【问题标题】：What are the limits to pushing JavaScript performance?推动 JavaScript 性能的限制是什么？
【发布时间】：2012-04-30 12:31:51
【问题描述】：

在过去的几个月里，我一直在构建一个原型页面，它使用了大量的 SVG，并且通常包含很多元素。在 JavaScript 和服务器端（大量 AJAX）中还处理了大量数据。页面上有数千个事件监听器。很重，这才是重点。

在 JS 中执行此类操作的最大障碍之一是单线程，当我必须执行 10 秒的计算时，它会锁定页面。有一些策略可以解决这个问题，但在 IE 支持 Web Workers 之前，并没有什么优雅的解决方案。此外，该页面可以使用超过 500MB 的内存，Chrome 似乎有时会遇到这种情况。

我想知道的是在 JavaScript 中构建这样的东西的可行性。我的代码远未优化，但让我们假设这个页面现在处理的负载是它所需要的——或者假设它需要更多。

我们还假设用户需要至少有一个中档桌面才能使用该应用程序。

人们是否如此努力地推动 JavaScript？就内存和 CPU 性能而言，它可以处理的内容有哪些限制？客户端和服务器端应该做多少？

编辑：我想每个人都会误解这个问题是不可避免的。我不是在寻求关于如何优化 JS 代码的建议。我在问在客户端处理多少处理和数据是合理的。是的，这取决于硬件，我试图通过说具有最新浏览器的中端桌面来回答，但实际上这不是重点。我想从概念上了解 JavaScript 在处理繁重的处理方面有多强大。在 JavaScript 中进行繁重的处理是否可行？

我希望每个人现在都能得到它。这是服务器端与客户端的比率。如果我必须运行具有 1000000 次迭代的循环，并且假设在 JS 中进行 X 迭代和在服务器上进行 Y 迭代之间进行选择没有成本，期望 JavaScript 处理多少是合理的？

【问题讨论】：

如果一个页面使用500MB内存，则需要重新开始
人们总是将 javascript 推向它的“极限”，几乎总是通过低效的代码。根据您自己的描述，您应该做的第一件事是尝试优化正在发生的事情。您可能会发现单个更改可能会释放数千个锁定 DOM 调用或其他内容，但如果没有深入分析，就无法真正说出您的情况发生了什么。
响应内存注释，它是可变的。一个 SVG 模块是几何查看器。所以更多的几何=更多的内存，我想知道的是你需要开始进行计算几何类型优化的点。如果 500MB 太高，那么合理的最高数量是多少？
@Ibu - “重新开始”是一种严重的夸大其词。将几十个尺寸不正确的图片放到一个页面上会占用 500MB。
这似乎不像 SO Q&A 格式所期望的那样真正有特定答案的问题。像这样的概念性问题可能属于programmers.stackexchange.com/about

标签： javascript performance

【解决方案1】：

1) 当然，您可以通过事件冒泡整合您的数千个事件侦听器。为不同的事件目标使用具有不同子例程的单个主事件处理程序将比众多特定处理程序更高效。

2) “在 IE 支持 Web Workers 之前，没有什么优雅的解决方案。”

Au contraire, mon frère：冻结浏览器可以通过以较小的块处理来缓解（如果可能的话，我会尝试将每个回调的时间保持在 100 毫秒以下）并执行超时后的下一步，这使浏览器有机会更新其状态并处理用户输入。

3) 如果您有大量元素，听起来 HTML5 Canvas 元素是比 SVG 更合适的解决方案。

4) “我的代码远未优化”

当您像这样突破极限时，算法优化会产生重大影响。

5) DOM 访问非常昂贵，因此可以通过巧妙地最小化 DOM 操作次数来获得巨大收益。确保你没有接触每个元素，一次一个。最好在一次 DOM 操作中重建整个混乱并替换它。

【讨论】：

【解决方案2】：

用户使用的系统是您可以面对但实际上无能为力的障碍。对于仍然在 512MB RAM 上运行 Pentium 的用户，以及雪上加霜的 IE6，webapps 会变得很糟糕。另一个问题是浏览器本身。 DOM 很慢。您应该尽可能避免接触 DOM。

您可以做的是改进您的代码，找到占用内存或进行过多处理的地方并将其分解。例如，当前可以通过使用超时和回调来补救单线程。这是one of my demos 处理一个很长的循环。一个执行同步操作，另一个使用超时来模拟异步操作。

您还可以将数据和处理任务卸载到服务器，使您的客户端应用程序成为“瘦客户端”。尽管 HTTP 请求可能会杀死您，但您在应用程序中执行其他操作时将服务器视为“第二个线程”。比如游戏。您可以计算分数、排名、比赛和服务器上的所有内容。不要让客户端这样做。只需让客户端成为服务器中正在发生的所有事情的“显示器”。

【讨论】：

我了解优化和服务器端与客户端处理的概念。我在问“有什么限制？”还没有人给我大概的数字。给定 X 的数据量和处理量，JavaScript 可以处理 X 的百分之几？一个页面在中端机器上可以处理的最大内存量是多少（仅限最新的浏览器）？
你实际上无法得到它的数字。每个人使用不同的机器。对于在英特尔超极本上运行 Chrome 的用户来说可以接受的东西，对于在华硕 Eee 上运行 IE8 的用户来说可能是不可接受的。这是您需要检查的另一个变量 - 您的目标受众。就像来自 ux.stackexchange 的人总是说：“做一些人口统计来找出你的目标受众”
问“有什么限制”就像问“一杯水有多大”。
@RobG Bravo 是一个恰当的比喻。爱它。这取决于上下文。对于现代台式机，我的猜测是数十兆字节的内存是可以的，但数百兆不是。如果我是你，托尼，我会通过在代表性系统上进行测试来凭经验回答这个问题。

【解决方案3】：

没有一成不变的限制。

可以在我的计算机上执行的操作与我在其上查找食谱的机器与我 4 岁的上网本上的操作会有所不同。内存、速度等取决于浏览器、cpu、ram 以及机器上运行的其他内容。我敢打赌，你在其他一些平台上运行你的代码，它会冻结，你必须行三指敬礼才能终止进程。

进行智能事件处理，检测较低级别的点击，而不是每个元素。
尽可能多地推送服务器以进行密集处理。
优化代码，确保不会在每次循环迭代时更新屏幕。
尽可能合并/最小化 http 请求。

【讨论】：