Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Benchmark is failing on slow computers #23

Closed
yurydelendik opened this issue Dec 5, 2024 · 3 comments
Closed

Benchmark is failing on slow computers #23

yurydelendik opened this issue Dec 5, 2024 · 3 comments

Comments

@yurydelendik
Copy link

yurydelendik commented Dec 5, 2024 •
edited
Loading

I'm getting the following error:

FluteComplex.TimeToMain(StartupTime): 1642000 us.
FluteComplex.TimeToFirstFrame(StartupTime): 2214000 us.
Null check operator used on a null value
_WidgetsFlutterBinding&BindingBase&GestureBinding&SchedulerBinding.handleDrawFrame@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js line 401 > WebAssembly.compile:wasm-function[773]:0x599ad
_WidgetsFlutterBinding&BindingBase&GestureBinding&SchedulerBinding._handleDrawFrame tear-off trampoline@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js line 401 > WebAssembly.compile:wasm-function[771]:0x59934
closure wrapper at file:///usr/local/google/home/kustermann/repositories/sdk-gclient3/sdk/wasm_gc_benchmarks/third_party/flute/engine/lib/src/platform_dispatcher.dart:580:21 trampoline@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js line 401 > WebAssembly.compile:wasm-function[757]:0x59401
closure wrapper at org-dartlang-sdk:///lib/_internal/wasm/lib/timer_patch.dart:89:66 trampoline@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js line 401 > WebAssembly.compile:wasm-function[763]:0x596ff
_invokeCallback@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js line 401 > WebAssembly.compile:wasm-function[165]:0x4a5f0
instantiate/_200/<@/Users/yury/dart-wasm-gc-benchmarks/benchmarks-out/flute.dart2wasm.mjs:167:53
eventLoop@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:342:15
async*self.dartMainRunner@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:365:14
@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:431:15

Unhandled rejection: ({})
Stack:
  eventLoop@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:352:11
  async*self.dartMainRunner@/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:365:14
  @/Users/yury/dart-wasm-gc-benchmarks/tools/run_wasm.js:431:15

The error is happening at

flute/framework/lib/src/scheduler/binding.dart

Line 1216 in c44fba2

_invokeFrameCallback(callback, _currentFrameTimeStamp!);

near _currentFrameTimeStamp! which means next frames was executed without begin frame.

I filed dart-lang/sdk#59666 for possible defect. Is anything can be done in flute to protect to keep begin and draw handlers together?
@mkustermann
Copy link
Member

Thanks for filing this, @yurydelendik !

See my analysis here: dart-lang/sdk#59666 (comment)

mkustermann added a commit to mkustermann/flute that referenced this issue Dec 6, 2024
@mkustermann
Schedule _drawFrame() timer before running _beginFrame()
2b48fc9 
A `_beginFrame()` seems to schedule the next frame interanally. If the
`_beginFrame()` takes a long time, it will finish after the expiration
date of the next frame timer.

That in return makes a `Timer.run(() => _drawFrame())` be scheduled
*after* the next frame callback is already run. Though we want to ensure
the `_beginFrame()` and `_drawFrame()` are together before starting to
work on the next frame. We only want microtasks to be drained in-between
those two.

(This is how C++ engine works)

We can get similar semantics by scheduling the `_drawFrame()` timer even
before running the `_beginFrame()` code.

Issue dart-lang#23
Issue dart-lang/sdk#59666
@mkustermann mkustermann mentioned this issue Dec 6, 2024
Open
copybara-service bot pushed a commit that referenced this issue Dec 10, 2024
@mkustermann
A _beginFrame() seems to schedule the next frame interanally. If th…
e4ea045 
…e `_beginFrame()` takes a long time, it will finish after the expiration date of the next frame timer.

That in return makes a `Timer.run(() => _drawFrame())` be scheduled *after* the next frame callback is already run. Though we want to ensure the `_beginFrame()` and `_drawFrame()` are together before starting to work on the next frame. We only want microtasks to be drained in-between those two.

(This is how C++ engine works)

We can get similar semantics by scheduling the `_drawFrame()` timer even before running the `_beginFrame()` code.

Issue #23
Issue dart-lang/sdk#59666

GitOrigin-RevId: 71e3edb
Change-Id: Ib2eb54d159d59a4e8e78a71682628160b66ff897
Reviewed-on: https://dart-review.googlesource.com/c/flute/+/399380
Reviewed-by: Lasse Nielsen <[email protected]>
Reviewed-by: Alexander Thomas <[email protected]>
Commit-Queue: Martin Kustermann <[email protected]>
@mkustermann
Copy link
Member

Small update: The issue I think caused this should be fixed now.

When I've time, I'll also roll this into https://github.com/mkustermann/wasm_gc_benchmarks (and update commandline shells, re-measure benchmarks, etc)

@eqrion eqrion mentioned this issue Jan 24, 2025
Merged
mkustermann added a commit to mkustermann/wasm_gc_benchmarks that referenced this issue Jan 28, 2025
@mkustermann
Roll third_party/flute with bugfix about scheduling frames
6d36e8e 
Issue dart-lang/flute#23
Issue dart-lang/sdk#59666
@mkustermann
Copy link
Member

The flute benchmark was fixed some time ago. We've rolled that fix into our CI & benchmarking infrastructure some time ago.

Today I've also rolled it into https://github.com/mkustermann/wasm_gc_benchmarks, so this should close this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@yurydelendik @mkustermann