Web Worker处理AJAX调用 – 优化过度杀毒？

我正在处理使用Web Workers处理所有AJAX请求的代码（如果可用）。这些工作者几乎没有什么比XMLHttpRequest对象处理（没有额外的计算）。所有由worker创build的请求都是asynchronous的（ request.open("get",url,true) ）。

最近，我得到了关于这个代码的几个问题，我开始怀疑是否应该花时间修复这个问题，或者只是抛出整个解决scheme。

到目前为止，我的研究表明，这个代码实际上可能会损害性能。但是，我无法find任何可信的来源支持这一点。我唯一的两个发现是：

有人能指点我一个可靠的来源讨论这个问题？或者，有没有可能消除我疑惑的基准？

[ 编辑 ]当WebWorker也负责parsing结果（ JSON.parse ）时，这个问题会变得更有趣。 asynchronous分析是否改善性能？

我已经为jsperf创build了一个适当的基准。取决于浏览器， WebWorker方法比原始Ajax调用慢85-95％ 。

笔记：

因为每个请求的networking响应时间可能不同，我只testingnew XMLHttpRequest()和JSON.parse(jsonString); 。没有真正的 AJAX调用正在进行。
WebWorker安装和拆卸操作没有被测量
请注意，我正在testing一个请求，对于多个同时请求，webworker方法的结果可能会更好
Calvin Metcalf向我解释说，在jsperf上比较同步和asynchronous不会给出准确的结果，他创build了另一个消除asynchronous开销的基准。结果仍然显示WebWorker方法显着较慢。
从Reddit讨论中我了解到，在主页面和WebWorker之间传递的数据被复制，并且必须在这个过程中被序列化。因此，使用WebWorker进行parsing只是没有多大意义，数据将不得不被序列化和反序列化，然后才能在主页上使用它们。

首先要记住的是，networking工作者很less花费更快的时间，因为他们把计算加载到后台线程，使得与用户交互相关的处理不会被阻塞。例如，当考虑到传输数据时，执行大量计算可能需要8秒而不是4秒。但是如果在主线程上完成，整个页面将被冻结4秒，这可能是不可接受的。

考虑到这一点，移动主线程的ajax调用将不会获得任何东西，因为ajax调用不是阻塞的。但是，如果你必须parsingJSON或更好的解决scheme，从一个大的请求中提取一个小的子集，然后networking工作者可以帮助你。

我听说但是没有得到证实的警告是，工作人员使用不同于主页面的caching，所以如果在主线程和工作人员中加载相同的资源，可能会导致大量的重复工作。

你正在优化你的代码在错误的地方。

AJAX请求已经在一个单独的线程中运行，一旦完成（并调用定义的callback函数），就返回到主事件循环。

Web工作人员是线程的接口，意味着计算上昂贵的操作。就像传统的桌面应用程序一样，当你不想用耗费很长时间的计算来阻塞界面时，

asynchronousIO是Javascript的一个重要概念。

首先，您的请求已经是asynchronous的，IO是非阻塞的，在您的请求期间，您可以运行任何其他的Javascript代码。在工作者中执行callback比请求更有趣。

其次，Javascript引擎在同一个线程中执行所有的代码，如果你创build新的线程，你需要处理与工作者消息api的数据通信（见Semaphore ）。

总而言之，JavaScript的asynchronous和单线程性质是非常强大的，尽可能多地使用它，并且只有在真正需要的时候才会创buildworker，例如在一个长的Javascript过程中。

根据我的经验，Web Workers 不应该用于AJAX调用。首先，它们是asynchronous的，这意味着在等待信息回来的时候代码仍然会运行。

现在，使用worker来处理响应肯定是你可以使用Web Worker的。一些例子：

编辑：另一个好的阅读将是：对networking工作者的同步请求的意见