Remove performance.mark and performance.measure etc. from Dart-flute-wasm code

[Constellation]

It seems that many performance.mark performance.measure etc. are emitted in Dart-flute-wasm. They are emitted from Dart wasm code like,

      _182: () => globalThis.JSON,
      _183: x0 => x0.measure,
      _184: x0 => x0.mark,
      _185: x0 => x0.clearMeasures,
      _186: x0 => x0.clearMarks,
      _188: (x0,x1,x2,x3) => x0.measure(x1,x2,x3),
      _190: (x0,x1,x2) => x0.mark(x1,x2),
      _191: x0 => x0.clearMeasures(),
      _193: x0 => x0.clearMarks(),
      _195: (x0,x1) => x0.parse(x1),

But we do not want to have a situation like, "To improve Dart-flute-wasm score, optimize performance.mark code path!". So I would like to suggest removing these performance entry emission from Dart-flute-wasm code.

[danleh]

If it's an easy patch, I'd be happy to remove those calls from the Dart-flute-wasm workload. That said, I don't think it's too important, see below.

@mkustermann I took a quick look, but couldn't find in the flute sources where performance.mark is called from exactly. A stack trace shows Timeline.startSync, but that seems to be some Dart framework code, not in flute?

Error: measure called
    at _183 (/usr/local/google/home/dlehmann/JetStream/Dart/build/flute.dart2wasm.mjs:196:33)
    at module0._performance implicit getter (wasm://wasm/module0-00531ece:wasm-function[1391]:0x607c2)
    at module0._isDartStreamEnabled (wasm://wasm/module0-00531ece:wasm-function[1420]:0x612fa)
    at module0.Timeline.startSync (wasm://wasm/module0-00531ece:wasm-function[1461]:0x62594)
    at module0.main (wasm://wasm/module0-00531ece:wasm-function[434]:0x45984)
    at module0._invokeMain (wasm://wasm/module0-00531ece:wasm-function[173]:0x408bb)
    at InstantiatedApp.invokeMain (/usr/local/google/home/dlehmann/JetStream/Dart/build/flute.dart2wasm.mjs:3099:37)
    at (d8):304:29
    at eventLoop ((d8):235:17)
    at Benchmark.runIteration ((d8):303:11)

How easy would it be to avoid these call?

It doesn't seem to be a big issue in practice to me though:

• I monkey-patched/hooked performance.mark/measure, and they are called exactly once per iteration, i.e., 15 times total in the workload (over a Wall time of ~10s)
• In a CPU profile of d8, the call stacks containing performance account for 0.005% of all samples, i.e., I think their effect is quite small.

[mkustermann]

There's two things

Only emit timeline events if not in release mode

Those timeline events are emitted from the flutter framework. They are supposed to only be emitted in non-release mode builds (e.g. debug or profile builds). The flute framework is an older copy of flutter framework code (with stubbed out skia calls).

There were more changes to flutter framework that moved some of the timeline code under guards. I've landed dart-lang/flute@6e44eea to backport one of them to the flute codebase.

Ensure we compile the flute benchmarks with release mode flags

When compiling the flute code we should be setting -Ddart.vm.product=true define. I've landed mkustermann/wasm_gc_benchmarks@e01db43 to do that and re-generated the flute benchmarks (also with newer Dart SDK) in mkustermann/wasm_gc_benchmarks@77f886e

@danleh Maybe we can roll mkustermann/wasm_gc_benchmarks@77f886e into JetStream?

[mkustermann]

Actually, there may be a little more code in flute that must be guarded with if (!kReleaseMode) {}. I'll look through it again. So, let's wait before rolling this.

[mkustermann]

There was one more usage, removed in dart-lang/flute@d5adc4d and rolled in mkustermann/wasm_gc_benchmarks@13951e1 which now also shows clearly the removal of those JS functions from the flute.*mjs file.

[danleh]

Awesome, thanks! Let's keep this open as a reminder, to include this update as part of #97.

[danleh]

Thanks to @mkustermann and @eqrion, we now rolled the new binaries into Dart-flute-complex-wasm and Dart-flute-todomvc-wasm, and call performance.mark/measure exactly once per iteration (in the driver). Closing.