这篇文章由 Vladimir Vukićević 撰写，转载自他的个人博客 。

快速 JavaScript 是现代 Web 的基石。在过去，应用程序作者必须等待浏览器开发人员在浏览器本身实现任何复杂的功能，才能从脚本代码中访问它。如今，许多这些功能可以直接迁移到 JavaScript 本身。这对于应用程序作者来说有很多优点：无需等待新版本的浏览器才能开发或发布您的应用程序，您可以根据自己的需求定制功能，并且可以直接改进它（使其更快、更高质量、更精确等）。

以下两个示例展示了使用改进的 JS 引擎和 Firefox 4 中将具备的功能可以实现什么。第一个示例展示了一个 简单的基于 Web 的暗房，它允许您对图像执行颜色校正。HTML+JS 代码约为 700 行，不包括 jQuery。它基于 Google 的 Native Client (NaCl) SDK 中包含的演示；在该演示中，颜色校正工作是在本机代码内通过 NaCl 完成的。该演示（最初被认为“太慢，无法在 JavaScript 中运行”）有几千行代码，并且涉及下载和安装特定于平台的编译器、测试/部署代码的多个步骤以及在浏览器端安装插件。

在我的 MacBook Pro 上，使用默认的缩小图像（每秒约 500 万像素——这个数字不会受到图像大小的影响），我获得了大约 15-16 帧每秒的性能，这对于实时操作来说已经足够快了。可以优化算法以进一步提高速度。JS 引擎的进一步优化也可以在这里提供帮助；例如，我注意到，由于画布 API 指定了图像数据处理方式，我们在将计算后的像素写回显示画布时，花费了大量时间进行浮点到整数的转换。

Web 暗房工具还支持拖放，因此您可以从计算机中获取任何图像并将其拖放到画布上以加载它。很久很久以前，在 2006 年，我写了一个名为“Croppr!”的插件。它旨在与 Flickr 一起使用，允许用户使用任何图像的自定义裁剪进行操作，然后在评论中留下裁剪建议，以便使用 Croppr 查看。它几乎肯定不再起作用了，但更新它会很不错：这次既有裁剪，又有颜色校正。然后，拥有该插件的人（也许是现在 Jetpack！）就可以访问 Flickr 照片并进行实验，然后为摄影师留下建议。

第二个示例基于 Dave Humphrey 和其他人一直在做的将音频操作引入 Web 平台的工作。最初，他们的规范包括一个预先计算的 FFT，它与每个音频帧一起提供给 Web 应用程序。我建议没有必要这样做——虽然 FFT 对某些应用程序很有用，但对于其他应用程序来说，它是浪费的工作。那些想要使用 FFT 的应用程序可以在 JS 中实现一个。一些基准数据支持了这一点——使用最初为 WebGL 创建的 类型化数组，在 JS 中计算 FFT 的速度接近本机代码。同样，两者都可以加速（也许在 JS 端使用 SSE2 或类似于 Mono.Simd 的东西），但它已经足够快，可以用作实用工具。

该演示展示了这一点。一个数值基准并不是真正有趣，所以相反，我获取一个视频片段，并在视频播放时，提取每一帧的绿色通道的一部分并计算其 2D FFT，然后显示出来。原始剪辑以每秒 24 帧的速度播放，因此这是该演示的上限。使用 Float32 类型化数组，计算和回放对我来说大约以 22-24 帧每秒的速度进行。

您可以抓住视频控件并滚动到特定帧。（帧率计算仅在视频正常播放时才是正确的，而不是在滚动时。）视频源使用 Theora，因此您需要一个可以播放 Theora 内容的浏览器。（我没有类似的剪辑使用 WebM，否则我可以使用它。）

这些示例展示了 Firefox 自 Firefox 3.5 以来一直用于加速 JavaScript 的基于跟踪的 JIT 技术的强大功能。但是，并非所有代码都能从这种类型的加速中看到如此显著的加速。因此，我们将为 Firefox 4 包含一个完整的基于方法的 JIT（有关更多详细信息，请参阅 David Anderson 的博客，以及 David Mandelin 的博客）。这将提供显著更快的基本 JS 性能，而跟踪 JIT 将成为它自然应用于的代码的涡轮增压器。

将快速的 JavaScript 性能与 WebGL 和音频等新的 Web 平台技术相结合，将带来一些非常令人兴奋的 Web 应用程序，我期待看到开发人员用它们做些什么！

编辑：我对演示做了一些最后一分钟的更改，结果导致了一个稍微损坏版本的 jQuery UI，它对 Safari 并不太满意。现在应该修复了！