1330558 - Explore using the presshell arena for FramePropertyTable

Status: NEW

(Core :: Layout, defect, P3)

Description

[Markus Stange [:mstange]]

Bug 1330187 shows that we have lots of cache misses during display list building.

We access lots of frame properties during display list building, so it would be good to increase cache locality by moving the frame property table into the PresShell arena.

nsTHashTable doesn't allow us to specify an allocator (as far as I know), so we might want to try out std::unordered_map instead.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

I think it'd be worth investigating how many frames don't have properties. If the percentage is low, we'd be better of just adding another field to frames instead of using a hash table.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

I also suspect that a bunch of cache misses and an easy performance improvement for quite a few parts of layout may be removing the nsIFrame::GetType virtual call. Moving the frame type into the frame instead of making it a virtual call, or at least a few bits indicating whether a frame is one of the frames we check the most, most notably placeholders, canvas, and frames like that could be an easy perf improvement I think.

I haven't had time to profile and gather data to verify whether that's true, but it's something that always rings the bell to me, since we access the type of the frame all the time from the frame constructor, ReflowInput and another bunch of specific frames (don't know whether the same is true for DL building though).

Also, note that we have 32 bits of padding in nsIFrame for 64-bit builds IIRC, so it should be doable to add a few fields in nsIFrame without any more memory usage in 64-bits.