One additional thought: after playing with this patch for a bit, I've started to suspect that counting only Wasm entered from interpreted JS might be missing some significant Wasm runtime: e.g., on the Godot Wasm demo ([link](http://godot.eska.me/pub/wasm-benchmark/)), the stat remains constant at ~300ms even after jumping around in the game for a while. An alternative low-overhead approach might be to measure all CPU time within *any* top-level JS invocation (hooking in at say JS::Call or thereabouts), i.e., any time the main loop enters user code. I suspect that measuring JS+Wasm time might be OK if we're measuring Wasm compiler changes and holding everything else constant; we won't have a speedup ratio for Wasm, but we will have absolute CPU time saved, to balance against compile time spent.
Bug 1656638 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
One additional thought: after playing with this patch for a bit, I've started to suspect that counting only Wasm entered from interpreted JS might be missing some significant Wasm runtime: e.g., on the Godot Wasm demo ([link](http://godot.eska.me/pub/wasm-benchmark/)), the stat remains constant at ~300ms even after jumping around in the game for a while. An alternative low-overhead approach might be to measure all CPU time within *any* top-level JS invocation (hooking in at say JS::Call or thereabouts), i.e., any time the main loop enters user JS or Wasm code. I suspect that measuring JS+Wasm time might be OK if we're measuring Wasm compiler changes and holding everything else constant; we won't have a speedup ratio for Wasm, but we will have absolute CPU time saved, to balance against compile time spent.
One additional thought: after playing with this patch for a bit, I've started to suspect that counting only Wasm entered from interpreted JS might be missing some significant Wasm runtime: e.g., on the Godot Wasm demo ([link](http://godot.eska.me/pub/wasm-benchmark/)), the stat remains constant at ~300ms even after jumping around in the game for a while. An alternative low-overhead approach might be to measure all CPU time within *any* top-level JS invocation (hooking in at say JS::Call or thereabouts), i.e., any time the main loop enters JS or Wasm code. I suspect that measuring JS+Wasm time might be OK if we're measuring Wasm compiler changes and holding everything else constant; we won't have a speedup ratio for Wasm, but we will have absolute CPU time saved, to balance against compile time spent.