7

我正在尝试编写一个执行可中断计算的网络工作者。我知道的唯一方法（除了Worker.terminate()）是定期屈服于消息循环，以便它可以检查是否有任何新消息。例如，这个 web worker 计算从 0 到 的整数之和data，但是如果你在计算过程中给它发送一条新消息，它将取消计算并开始一个新的计算。

let currentTask = {
  cancelled: false,
}

onmessage = event => {
  // Cancel the current task if there is one.
  currentTask.cancelled = true;

  // Make a new task (this takes advantage of objects being references in Javascript).
  currentTask = {
    cancelled: false,
  };
  performComputation(currentTask, event.data);
}

// Wait for setTimeout(0) to complete, so that the event loop can receive any pending messages.
function yieldToMacrotasks() {
  return new Promise((resolve) => setTimeout(resolve));
}

async function performComputation(task, data) {
  let total = 0;

  while (data !== 0) {
    // Do a little bit of computation.
    total += data;
    --data;

    // Yield to the event loop.
    await yieldToMacrotasks();

    // Check if this task has been superceded by another one.
    if (task.cancelled) {
      return;
    }
  }

  // Return the result.
  postMessage(total);
}

这行得通，但速度慢得惊人。在我的机器上，循环的每次迭代平均while需要 4 毫秒！如果您想快速取消，这是一个相当大的开销。

为什么这么慢？有没有更快的方法来做到这一点？

4

4 回答 4

3

是的，消息队列将比超时具有更高的重要性，因此会以更高的频率触发。

您可以使用MessageChannel API轻松绑定到该队列：

let i = 0;
let j = 0;
const channel = new MessageChannel();
channel.port1.onmessage = messageLoop;

function messageLoop() {
  i++;
  // loop
  channel.port2.postMessage("");
}
function timeoutLoop() {
  j++;
  setTimeout( timeoutLoop );
}

messageLoop();
timeoutLoop();

// just to log
requestAnimationFrame( display );
function display() {
  log.textContent = "message: " + i + '\n' +
                    "timeout: " + j;
  requestAnimationFrame( display );
}
<pre id="log"></pre>

现在，您可能还希望在每个事件循环中批处理几轮相同的操作。

以下是此方法有效的几个原因：

  • 根据规范，setTimeout在第 5 级调用之后，即 OP 循环的第五次迭代之后，将被限制到至少 4 毫秒。
    消息事件不受此限制。

  • 在某些情况下，某些浏览器会使由 发起的任务setTimeout具有较低的优先级。
    也就是说，Firefox 在页面加载时会这样做，因此此时调用的脚本setTimeout不会阻塞其他事件；他们甚至为此创建了一个任务队列。
    即使仍未指定，似乎至少在 Chrome 中，消息事件具有“用户可见”优先级，这意味着某些 UI 事件可能首先出现，但仅此而已。（使用 Chrome 中即将推出的scheduler.postTask()API 对此进行了测试）

  • 大多数现代浏览器会在页面不可见时限制默认超时，这甚至可能适用于 Workers。
    消息事件不受此限制。

  • 正如 OP 所发现的，Chrome 确实为前 5 次调用设置了至少 1 毫秒。

但是请记住，如果所有这些限制都被设置了setTimeout，那是因为以这样的速率调度这么多任务是有成本的。

仅在 Worker 线程中使用它！

在 Window 上下文中执行此操作将限制浏览器必须处理的所有正常任务，但他们会认为这些任务不太重要，例如网络请求、垃圾收集等。
此外，发布新任务意味着事件循环必须在频率高，永远不会闲置，这意味着更多的能量消耗。

于 2020-04-21T08:34:43.560 回答
2

为什么这么慢？

Chrome (Blink) 实际上将最小超时设置为 4 毫秒：

// Chromium uses a minimum timer interval of 4ms. We'd like to go
// lower; however, there are poorly coded websites out there which do
// create CPU-spinning loops.  Using 4ms prevents the CPU from
// spinning too busily and provides a balance between CPU spinning and
// the smallest possible interval timer.
static constexpr base::TimeDelta kMinimumInterval =
    base::TimeDelta::FromMilliseconds(4);

编辑：如果您在代码中进一步阅读，则仅在嵌套级别超过 5 时才使用该最小值，但在所有情况下它仍将最小值设置为 1 毫秒：

  base::TimeDelta interval_milliseconds =
      std::max(base::TimeDelta::FromMilliseconds(1), interval);
  if (interval_milliseconds < kMinimumInterval &&
      nesting_level_ >= kMaxTimerNestingLevel)
    interval_milliseconds = kMinimumInterval;

显然，WHATWG 和 W3C 规范对于是否应该始终应用至少 4 毫秒或仅适用于某个嵌套级别以上存在分歧，但 WHATWG 规范对 HTML 很重要，而且 Chrome 似乎已经实现了这一点。

我不确定为什么我的测量结果表明它仍然需要 4 毫秒。

有没有更快的方法来做到这一点？

基于 Kaiido 使用另一个消息通道的好主意，您可以执行以下操作：


let currentTask = {
  cancelled: false,
}

onmessage = event => {
  currentTask.cancelled = true;
  currentTask = {
    cancelled: false,
  };
  performComputation(currentTask, event.data);
}

async function performComputation(task, data) {
  let total = 0;

  let promiseResolver;

  const channel = new MessageChannel();
  channel.port2.onmessage = event => {
    promiseResolver();
  };

  while (data !== 0) {
    // Do a little bit of computation.
    total += data;
    --data;

    // Yield to the event loop.
    const promise = new Promise(resolve => {
      promiseResolver = resolve;
    });
    channel.port1.postMessage(null);
    await promise;

    // Check if this task has been superceded by another one.
    if (task.cancelled) {
      return;
    }
  }

  // Return the result.
  postMessage(total);
}

我对这段代码并不完全满意，但它似乎确实有效并且速度更快。在我的机器上，每个循环大约需要 0.04 毫秒。

于 2020-04-21T08:40:48.973 回答
0

查看我的另一个答案中的反对票，我试图用我的新知识来挑战这个答案setTimeout(..., 0)中的代码，该知识有大约 4 毫秒的强制延迟（至少在 Chromium 上）。我在每个循环中放置了 100 毫秒的工作负载，并setTimeout()在工作负载之前进行了安排，这样setTimeout()4 毫秒就已经过去了。postMessage()为了公平起见，我对 进行了同样的操作。我还更改了日志记录。

结果令人惊讶：在观察计数器时，消息方法在开始时比 timeout 方法获得了 0-1 次迭代，但即使达到 3000 次迭代，它也保持不变。– 这证明setTimeout()具有并发的 apostMessage()可以保持其份额（在 Chromium 中）。

将 iframe 滚动到范围之外会改变结果：与基于超时的工作负载相比，处理的消息触发工作负载几乎是 10 倍。这可能与浏览器打算将更少的资源交给 JS 的视图或另一个选项卡等有关。

在 Firefox 上，我看到一个带有 7:1 消息的工作负载处理超时。观看它或让它在另一个选项卡上运行似乎并不重要。

现在我将（稍作修改的）代码移到了一个Worker 上。事实证明，通过超时调度处理的迭代与基于消息的调度完全相同。在 Firefox 和 Chromium 上，我得到了相同的结果。

let i = 0;
let j = 0;
const channel = new MessageChannel();
channel.port1.onmessage = messageLoop;

timer = performance.now.bind(performance);

function workload() {
  const start = timer();
  while (timer() - start < 100);
}

function messageLoop() {
  i++;
  channel.port2.postMessage("");
  workload();
}
function timeoutLoop() {
  j++;
  setTimeout( timeoutLoop );
  workload();
}

setInterval(() => log.textContent =
  `message: ${i}\ntimeout: ${j}`, 300);

timeoutLoop();
messageLoop();
<pre id="log"></pre>

于 2020-06-11T16:50:09.863 回答
-2

我可以确认 4ms 的往返时间setTimeout(..., 0)，但不一致。我使用了以下工作人员（以 开始let w = new Worker('url/to/this/code.js'，以 停止w.terminate()）。

在前两轮中，暂停时间低于 1 毫秒，然后我得到一个在 8 毫秒范围内的暂停，然后每次进一步迭代都保持在 4 毫秒左右。

为了减少等待，我将yieldPromise执行器移到了工作负载前面。这种方式setTimeout()可以保持它的最小延迟，而不会暂停工作循环超过必要的时间。我想工作量必须超过 4ms 才能有效。这应该不是问题，除非捕获取消消息是工作量...... ;-)

结果：仅约 0.4 毫秒延迟。即至少减少 10 倍。1

'use strict';
const timer = performance.now.bind(performance);

async function work() {
    while (true) {
        const yieldPromise = new Promise(resolve => setTimeout(resolve, 0));
        const start = timer();
        while (timer() - start < 500) {
            // work here
        }
        const end = timer();
        // const yieldPromise = new Promise(resolve => setTimeout(resolve, 0));
        await yieldPromise;
        console.log('Took this time to come back working:', timer() - end);
    }
}
work();


1浏览器不是将计时器分辨率限制在该范围内吗？那么没有办法衡量进一步的改进......

于 2020-06-10T22:11:00.657 回答