1397386 - stylo: LonghandId::parse_value is enormous

Status: RESOLVED DUPLICATE of bug 1351737

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Nathan Froyd [:froydnj]]

bloaty says this function is 218K on my Linux x86-64 nightly.  This is the biggest function in libxul by a large margin.

Looking at the code, I think this is partly just an effect of inlining--there's no obvious duplicated generated code that can be factored out.  But maybe there's a smarter way to factor out parsing code for commonly-typed properties?

Comment 1

[Bobby Holley (:bholley)]

Simon, is there anything we can do here?

Comment 2

[(Away)]

(In reply to Nathan Froyd [:froydnj] from comment #0)
> bloaty says this function is 218K on my Linux x86-64 nightly.  This is the
> biggest function in libxul by a large margin.

This honor(?) used to go to ParsedDeclaration::parse and then ParsedDeclaration::parse_into in bug 1351737, so this is probably just names shifting around as a result of refactoring and/or different inlining choices. We might be able to close out one of the two bugs.

Comment 3

[Simon Sapin (:SimonSapin)]

I can reproduce this on official Nightly builds (`bloaty -d symbols -n 0 libxul.so` lists LonghandId::parse_value as the third largest symbol at 224 KiB, after gExponentialBucketLowerBounds and sWebMSample) but not on a local build: there, it is 29th at 45.6 KiB. A major difference that I can think of is that I’m using Rust 1.20.0, whereas Nightly is probably built with 1.19.0 since bug 1396884 has not landed yet.

Downgrading to 1.19.0, LonghandId::parse_value is now 18th at 59.2 KiB. So there’s something else going on…


In any case, :dmajor is correct that this is the same code (parsing for values of longhand properties) that was previously in ParsedDeclaration::parse_into. The symbol names change as we move things around, but I don’t think there is anything fundamentally new here compared to bug 1351737.