1351399 - [meta] Profile cache misses in display list + FrameLayerBuilder code

Status: NEW

(Core :: Web Painting, enhancement, P2)

Description

[Markus Stange [:mstange]]

I ran valgrind on the first 36 painted frames of the 20000 divs animation testcase at https://people-mozilla.org/~jmuizelaar/implementation-tests/dl-test.html using

valgrind --tool=callgrind --cache-sim=yes --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --read-inline-info=yes --trace-children=yes ./dist/bin/firefox

and am attaching the resulting profile here. We might find useful information in it. I don't know how well the symbol information transfers between machines.

Comment 1

[Markus Stange [:mstange]]

Attachment: callgrind.out.23169.tar.gz

Can be opened using KCacheGrind.

Comment 2

[Julian Seward [:jseward]]

(In reply to Markus Stange [:mstange] from comment #0)
> I don't know how well the symbol information transfers between machines.

It looks to me like everything transfers OK, except for the sources,
so it can't show annotated source code.  Paths like
 /home/mstange/code/mozilla/layout/painting/FrameLayerBuilder.cpp
have apparently been baked into the profile file.

Looks like you have some interesting numbers to look at.  This profile
shows 27.6M LL misses, of which 13.9M are from nsIFrame::BuildDisplayListForChild
and its dependents.  The L1 miss numbers show an even greater percentage
of the total -- 474M out of a total of 534M.

Comment 3

[Markus Stange [:mstange]]

Attachment: callgrind.out.29290.tar.gz

New profile from revision 6dfa56094f0c. AssertDisplayItemData causes the most expensive hash table related data read misses.