Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Proposal: Expose engine-defined compute timing for WebNN (`MLComputeTiming`)

オープン
  • 何か問題がありますか？
#963 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript
領域
api, machine-learning

調査の方向性

Read the WebNN explainer when it is published and review the open questions listed in this issue: entry naming, graph ID, accelerated status, and computeDuration semantics. Then identify the WebNN specification sections for the graph API and Model Loader, plus the WebPerf timing entry types registry. Done means the proposal's semantics and registry relationship are resolved and specified for both surfaces.

索引モデルが issue の本文から書いたものです。

説明

Problem

  • WebNN has no performance surface: no timing, no attribution.
  • dispatch() has no completion signal: "callers can await the results of reading back the
    output tensors."
  • The only way for a page to learn that a run finished is a readback — so the readback becomes
    part of the number, and the bracket differs per engine. Page-timed numbers are not interoperable.

Scenario

A page runs a face detector and wants to pick a smaller model on a slow device. It cannot tell
whether the slow device is limited by the model, the hardware, or its own input preparation.
The only measurement it can take is this:

const start = performance.now();
context.dispatch(graph, inputs, outputs);
await context.readTensor(a);          // the only completion signal
await context.readTensor(b);
console.log(`Inference: ${(performance.now() - start).toFixed(2)}ms`);

On a reference mobile device (NPU backend):

measurement how it was taken value
actual graph execution engine timestamps around the backend run 5.69 ms
dispatch round trip page timer around dispatch() only 5.85 ms
the code above dispatch() + two awaited readTensor() calls 209.23 ms

The page's "inference" is 209 ms against 5.7 ms of computation, and it cannot see the difference.

Proposal

MLComputeTiming: a PerformanceEntry interface with two engine-created entry types.

[Exposed=(Window,Worker)]
interface MLComputeTiming : PerformanceEntry {
  readonly attribute DOMHighResTimeStamp computeDuration;
  readonly attribute boolean accelerated;
  [Default] object toJSON();
};
entryType created when
ml-compile compilation completes, incl. initialization (build())
ml-compute one graph execution completes (dispatch())
  • One entry per execution, never per operator.
  • Observer-only: availableFromTimeline: false, delivered through PerformanceObserver.
  • duration = submission → completion (queueing included); computeDuration = the engine's own
    compute interval inside it.
  • graphId (engine-assigned, per context) correlates compile and run entries; accelerated is
    one bit.

Relations

  • #934 (effective compute policy):
    complementary — this contributes measurements and the privacy framing, not a device surface.
  • #923 (compute policy rename):
    decides the long-term shape of the accelerated field.
  • Model Loader (draft): the same entries are
    designed to cover its load() / compute() once that API stabilises.
  • WebPerf: the entry types need a row in the timing entry types registry. WebNN owns the
    semantics; WebPerf owns the registration.

Measurements, alternatives, privacy and the open questions (naming, graphId vs MLGraph.id,
accelerated shape, computeDuration normativity) are in the explainer: link when published.

主要言語
Bikeshed
スター
566
フォーク
72
平均マージ
6日 5時間
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

webmachinelearning/webnn のほかの issue

webmachinelearning/webnn の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。