1348697 - Optimize away OverflowAreasProperty more often

Status: NEW

(Core :: Layout, enhancement)

Description

[Mats Palmgren (inactive)]

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.

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

(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.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 3

[Jet Villegas (inactive)]

(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?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Leaving this as qf:p1, although maybe worth reprofiling after bug 1365982.

Comment 6

[Daniel Holbert [:dholbert]]

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.)

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.