This can be viewed at page 4 of the internal stats display (i or I).
CPU time report is the same as at lua.c, but untested - doesn't seem
to work on windows - also not for lua.
TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats.
This also almost doubles the memory usage by js scripts.
For memory reporting, we don't have enough info by default, because
even when using a custom allocator, mujs doesn't report the old size
(on free or realloc) because it doesn't track this value, and as
a result we can't track the overall size.
Our option are either to track the size of each allocation on our own,
or use talloc which tracks this value.
However, using talloc for mujs allocations adds a considerable
overhead, and almost doubles(!) the overall memory used, because each
individual allocation includes a considerable talloc header, and mujs
does many small allocations.
So our solution is that by default we behave like previously - not
using a custom allocator with mujs, and stats does not display memory
usage for js scripts.
However, if the env var MPV_LEAK_REPORT is set to 1, then we use
a custom allocator with talloc and track/report memory usage.
We can't switch allocator at runtime, so an mpv instance either tracks
or doesn't track js scripts memory usage, according to the env var.
(we could use a property and apply it whenever a new script starts,
so that it could change for newly launched scripts, but we don't).
Keys and lines-to-scroll are configurabe, and the scroll keys are only
bound on pages which support scrolling (currently only page 4) - also
during oneshot (like the page-switching keys).
Scroll offset is reset for all pages on any key - except scroll keys, so
that entering or switching to a page resets the scroll, as well as when
"re-entering" the same page or "re-activating" the stats oneshot view.
TODO: print_page(..) is highly associated with extending the oneshot
timer if required. The timer handling can probably move into print_page
and removed from all the places which boilerplate its management.
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
Avi Halachmi (:avih)
Julian
wm4