Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#963 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
api, machine-learning

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Bikeshed
Stelle
566
Fork
72
Merge medio
6g 5h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di webmachinelearning/webnn

Tutte le issue di webmachinelearning/webnn

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.