In bug 1385154 we avoid storing any ComputedValues generated for ::before and ::after if it didn't result in any effective generated content. It would be nice to do this check after matching and before producing the ComputedValues, to avoid a lot of churn.

Hmm, that's very orange...

Comment on attachment 8901633 [details] Bug 1394271 - style: Don't produce ComputedValues for ::before/::after just to throw them away. https://reviewboard.mozilla.org/r/173036/#review178444 Per IRC chat I think I'd like to make sure this actually improves things (doing that now), but this otherwise looks good. ::: servo/components/style/rule_tree/mod.rs:1286 (Diff revision 2) > + /// `content: none` or `content: normal`. > + pub fn has_effective_generated_content_declarations( > + &self, > + guards: &StylesheetGuards, > + ) -> bool { > + use properties::longhands::display::SpecifiedValue as Display; nit: I believe everywhere else we use `display` (lowercased) and `content`. ::: servo/components/style/rule_tree/mod.rs:1298 (Diff revision 2) > + let style_source = node.style_source(); > + if matches!(*style_source, StyleSource::None) { > + continue; > + } > + > + for &(ref decl, importance) in node.style_source() nit: You have a `style_source` variable in scope already. ::: servo/components/style/rule_tree/mod.rs:1310 (Diff revision 2) > + if !found_display { > + if let PropertyDeclaration::Display(display) = *decl { > + if display == Display::none { > + return false; > + } > + if found_content { nit: maybe this would be easier to reason about (and shorter) with ``` if found_display && found_content { return true; } ``` below the two `if`s. wdyt? ::: servo/components/style/style_resolver.rs:115 (Diff revision 2) > + if !pseudo.is_before_or_after() { > + return false; > + } > + > + if let Some(visited_rules) = visited_rules { > + if visited_rules.has_effective_generated_content_declarations(guards) { I don't think we need to check visited rules, since we only probe the non-visited style to determine whether to generate a pseudo.

Given that we're already tracking the high-level memory issue in bug 1289864, I think we probably don't need to track all the sub-bugs as P1.

status-firefox57=wontfix unless someone thinks this bug should block 57