It seems to me we could optimize away OverflowAreasProperty more often. http://searchfox.org/mozilla-central/rev/c9f5cc6b4593d461e87a6221dc0286b3859fd515/layout/generic/nsFrame.cpp#8545 From the top of my head: 1. We currently use a property if one of the sides is 0xff. It seems we could store 0xff as long as not all four are 0xff and then use 0xffffffff to indicate a property. This would give us one more bit per side in many cases. 2. I guess the two common cases are: a small visual overflow on all four sides (an outline/box-shadow), or a large scrollable overflow on one or two sides (a constrained size container with overflowing children). We could store larger values if we encoded the sides... 3. It's very common that Scrollable==Visual overflow, so we could encode that special case in some way (we currently always use a property if there is Scrollable overflow). 4. Maybe we could store approximate values, say rounded up to the nearest pixel? Then we can avoid a property in more cases.
(In reply to Mats Palmgren (:mats) from comment #0) > 4. Maybe we could store approximate values, say rounded up to > the nearest pixel? Then we can avoid a property in more cases. So we currently store appunits? Hmmm... probably we really should use devpx at least, or even CSS pixel. Another thought based on this would be using a logarithmic way to store when the number is larger than a certain value, e.g. 239, and making the rest of number meaning 2 << (n - 240 + 8), so that we can extensively expand the range.
I think it's worth measuring how frequent these cases are before optimizing for them; some of them sound like they may be extremely rare.
(In reply to David Baron :dbaron: ⌚️UTC+8 from comment #2) > I think it's worth measuring how frequent these cases are before optimizing > for them; some of them sound like they may be extremely rare. Mats: did you see this show up in your profiles?
Another thought is that we could use the packed overflow representation for both scrollable and visual overflow, and increasing the size from 8-bit to 16-bit.
Leaving this as qf:p1, although maybe worth reprofiling after bug 1365982.
As 57 approaches, we want to focus [qf:p1] on bugs that are known wins in important benchmarks & in sites with high usage. I don't think this bug fits that criteria, since: - we don't know how frequently this shows up in profiles (comment 3 & comment 5) - we don't know the frequency of the cases we'd be optimizing for (comment 2) So, it doesn't make sense to track this as a qf:p1 bug at this point. Let's downgrade this to qf:p3. (Still tentatively worth fixing as a perf bug, but not as high priority as other qf:p1 bugs.)