Currently the system memory measurements ("resident", "vsize", etc.) are
not reported through the generic memory reporting mechanism, simply
because they pre-date that mechanism. This changeset removes that
special-casing.
One consequence of this is that previously if a platform didn't
implement one of the basic measurements, a '???' entry would be printed.
Now nothing will be printed. This is no great loss and matches what
Firefox does.
Another consequence is that the order in which the measurements are
printed is changed. I plan to fix this soon so that reports are sorted
in a more sensible fashion.
Currently the system memory measurements ("resident", "vsize", etc.) are
not reported through the generic memory reporting mechanism, simply
because they pre-date that mechanism. This changeset removes that
special-casing.
One consequence of this is that previously if a platform didn't
implement one of the basic measurements, a '???' entry would be printed.
Now nothing will be printed. This is no great loss and matches what
Firefox does.
Another consequence is that the order in which the measurements are
printed is changed. I plan to fix this soon so that reports are sorted
in a more sensible fashion.
Currently if you don't specify the '-m' option, a fake do-nothing memory
profiler thread gets created instead of the real one. It ignores all
events except for `Exit`. And the timer thread doesn't get created so no
`Print` events are sent.
This changeset instead always creates the real thread. If you specify
'-m' the *timer* thread is still absent and it won't print anything.
However, the memory profiler thread will respond to register/unregister
events, which is good, because if there's a bug in those (e.g.
double-registration of a particular name) it'll show up in invocations
that lack '-m'.
This changeset implements the beginnings of fine-grained measurement of
Servo's data structures.
- It adds a new `SizeOf` trait, which is used to measure the memory used
by heap data structures, and implements it for some std types: Box,
String, Option, Arc, Vec, and DList.
- It adds a new `MemoryReporter` trait which is used to report memory
measurements from other threads to the memory profiler. Reporters are
registered and unregistered with the memory profiler, and the memory
profiler makes measurement requests of reporters when necessary.
- It plumbs a MemoryProfilerChan through to the layout task so it can
register a memory reporter.
- It implements the `SizeOf` trait for `DisplayList` and associated
types, and adds a memory reporter that uses it.
The display list hits 14.77 MiB when viewing
tests/html/perf-rainbow.html, and 2.51 MiB when viewing the Guardians of
the Galaxy Wikipedia page from servo-static-suite. Example output:
0.29: display-list::http://www.reddit.com/
0.00: display-list::http://static.adzerk.net/reddit/ads.html?sr=-reddit.com,loggedout&bust2#http://www.reddit.com
0.00: display-list::http://www.reddit.com/static/createadframe.html
There are a number of FIXME comments indicating sub-optimal things. This
is a big enough change for now that doing them as follow-ups seems best.
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
This patch will iterate through the DisplayList after the reflow
is done and print its elements (as also any sub-lists associated
to a child node stacking context).
It adds a new CLI parameter to trigger the function to dump the display list
to console (i.e. servo --debug dump-display-list url).
Using both display list and flow tree information is helpful to debug
rendering issues.
Previously this used the number of layout threads to allocate the
threadpool. This also makes the member name consistent with the rest of
the structure.
Although Rust allocations are on the jemalloc heap, allocations done by
Skia and the graphics driver are on the system heap, so it's worth
reporting that as well.
One thing I'm not sure about: I think mallinfo() might be a glibc-only thing, and I'm not sure if `target_os="linux"` implies glibc for Servo. So confirmation of that would be good.
Although Rust allocations are on the jemalloc heap, allocations done by
Skia and the graphics driver are on the system heap, so it's worth
reporting that as well.
