Expand description
What the JavaScript side costs, per frame.
The renderer has published real timings for a while: resolve, paint and
present. Script execution had none, so a profile could show a 4ms frame and
a UI that still felt slow, with nothing in between to look at. Every
reactive update, event handler, timer callback and microtask drain runs
through ScriptDocument::poll, so timing that one boundary accounts for the
whole language runtime without threading a clock through Boa.
Deliberately mirrors blitz_shell::frame_stats: a bounded ring, means and
tails rather than a running average, and no data reported as zero when there
is no data at all.
Structs§
- Boundary
Counters - What crossed from JavaScript into the host, in bytes.
- Script
Stats Snapshot - Mean, 95th percentile and worst case for the retained polls, in milliseconds.
- Timed
- The zero-cost stand-in. Same call sites, no clock, no bucket, no drop glue.
Functions§
- boundary_
counters - What has crossed on this thread since the last
reset_boundary_counters. - clear
- Discard every retained script and DOM timing sample.
- latest_
script_ stats Noneuntil script has actually run, so a caller reports “no data” rather than printing zeros that look like a measurement.- record_
poll - Record one
poll. Cheap enough to leave on: a lock and a push. - record_
static - Attribute a slice of script time to a fixed source, without allocating.
- record_
work - Attribute a slice of script time to a named source.
- reset_
boundary_ counters - Zero the boundary counters for this thread.
- work_
breakdown - The costliest sources seen so far, worst total first.