Closed
Bug 1435230
Opened 6 years ago
Closed 6 years ago
0.46 - 0.48% installer size (windows2012-32, windows2012-64) regression on push 6f0232cb2c79b23c6a21037a9de0772902853d18 (Mon Jan 22 2018)
Categories
(Core :: Graphics: Text, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox58 | --- | unaffected |
firefox59 | --- | unaffected |
firefox60 | - | disabled |
firefox61 | --- | fixed |
People
(Reporter: igoldan, Assigned: jwatt)
References
Details
(Keywords: regression, Whiteboard: gfx-noted)
Attachments
(1 file)
1.13 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
We have detected a build metrics regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=6f0232cb2c79b23c6a21037a9de0772902853d18 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 0.5% installer size windows2012-64 pgo 61,519,605.08 -> 61,813,298.50 0.5% installer size windows2012-32 pgo 57,569,080.42 -> 57,835,570.83 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=11391 On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the jobs in a pushlog format. To learn more about the regressing test(s), please see: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Automated_Performance_Testing_and_Sheriffing/Build_Metrics
Reporter | ||
Updated•6 years ago
|
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Reporter | ||
Comment 1•6 years ago
|
||
:RyanVM We just started to investigate even the smaller installer size regressions. I believe there's nothing really we can do about bug 1428819. Am I right? I filed this for tracking purposes.
Flags: needinfo?(ryanvm)
Comment 2•6 years ago
|
||
Yeah, pretty unlikely we'll be able to do much about it. I didn't think we even really used FreeType on Windows.
Flags: needinfo?(ryanvm)
Comment 3•6 years ago
|
||
Jonathan, do we indeed need FreeType on Windows? More generally, this seems like a lot of code size for a library update. Are we using all the functionality, or can we compile some of it out?
Flags: needinfo?(jfkthame)
Comment 4•6 years ago
|
||
I was a bit surprised by this at first, as in general we don't use FT on Win; but then I realized it's probably because PDFium depends on freetype. I don't know details of that dependency, or how the build is managed. It wouldn't surprise me if there is the potential to trim it down somewhat, but it'd require some digging. (Who looks after our PDFium integration?)
Flags: needinfo?(jfkthame)
Comment 5•6 years ago
|
||
Probably nobody at the moment. PDFium was being worked on by TDC.
Comment 6•6 years ago
|
||
Peter, do you own this now? If not, can you work with management to figure out who should be responsible for this?
Flags: needinfo?(peterv)
Updated•6 years ago
|
Whiteboard: gfx-noted
Reporter | ||
Updated•6 years ago
|
status-firefox58:
--- → unaffected
status-firefox59:
--- → unaffected
status-firefox60:
--- → affected
status-firefox-esr52:
--- → unaffected
Updated•6 years ago
|
Priority: -- → P3
Comment 7•6 years ago
|
||
Is this only a problem on Windows nightly builds? Seems like we build FT for SkiaPDF, and that was turned on in bug 1322540. Jonathan, what's the status of the printing integration?
Flags: needinfo?(peterv) → needinfo?(jwatt)
Assignee | ||
Comment 8•6 years ago
|
||
(In reply to Peter Van der Beken [:peterv] from comment #7) > Is this only a problem on Windows nightly builds? > > Seems like we build FT for SkiaPDF, and that was turned on in bug 1322540. > Jonathan, what's the status of the printing integration? If it's only SkiaPDF that pulls in the FT dependency, then yes, FT should only affect the size of Nightly builds. The only place we default to building SkiaPDF is for Nightly in toolkit/moz.configure here: https://dxr.mozilla.org/mozilla-central/rev/a6f5fb18e6bcc9bffe4a0209a22d8a25510936be/toolkit/moz.configure#978 None of our mozconfig files specify --enable-skia-pdf so this shouldn't be affecting Beta or Release. Regarding the status of printing, pdfium has been shelved so I don't think there's any reason for us to build SkiaPDF on Windows.
Flags: needinfo?(jwatt)
Assignee | ||
Comment 9•6 years ago
|
||
Assignee: nobody → jwatt
Attachment #8958182 -
Flags: review?(mh+mozilla)
Updated•6 years ago
|
Attachment #8958182 -
Flags: review?(mh+mozilla) → review+
Updated•6 years ago
|
status-firefox60:
affected → ---
Comment 10•6 years ago
|
||
Pushed by jwatt@jwatt.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/c2dafc93af5e Don't build SkiaPDF for Windows Nightly. r=glandium
Comment 11•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c2dafc93af5e
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Reporter | ||
Comment 12•6 years ago
|
||
Big installer size reduction on Nightly: == Change summary for alert #12244 (as of Mon, 19 Mar 2018 07:29:51 GMT) == Improvements: 4% installer size windows2012-64 pgo 63,300,324.04 -> 60,787,776.50 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=12244
Comment 13•6 years ago
|
||
I don't think we need this on Beta because we were only building it on Nightly to begin with, but feel free to correct me and request uplift if that's wrong.
status-firefox60:
--- → disabled
tracking-firefox60:
--- → -
You need to log in
before you can comment on or make changes to this bug.
Description
•