0.14 - 0.02% installer size / installer size (OSX) regression on Fri March 11 2022
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox98 | --- | unaffected |
| firefox99 | --- | unaffected |
| firefox100 | --- | fixed |
People
(Reporter: aesanu, Assigned: masayuki)
References
(Regression)
Details
(Keywords: perf-alert, regression)
Attachments
(2 files)
Perfherder has detected a build_metrics performance regression from push d7c979cbcbcc8eb1a611e6f6e6e5f907b453d620. As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
| Ratio | Test | Platform | Options | Absolute values (old vs new) |
|---|---|---|---|---|
| 0.14% | installer size | osx-shippable | instrumented | 117,514,786.88 -> 117,674,335.08 |
| 0.02% | installer size | osx-shippable | instrumented | 117,549,809.79 -> 117,568,832.83 |
Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.
For more information on performance sheriffing please see our FAQ.
|
||
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1742933
|
Assignee | |
Comment 2•3 years ago
|
||
Interesting. If it's caused by bug 1742933, the lambda callback functions could increase the binary size. However, I'm not so familiar with this issue. I'm currently guessing the the following approaches could fix:
- Make the default lambda callback be a static method.
- Stop capturing all things.
According to the regression range, the latter could fix this. I'll try.
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 3•3 years ago
•
|
||
The patches for bug 1742933 increases xul.dll file size of debug build on Windows over 50%, and my 2nd idea in comment 2 almost fixes it.
On the other hand, it seems that this does not affect installer size.
Therefore, I tried to check whether my patches for bug 1742933 is actually caused the big difference (first table row's result in comment 0). The result is here:
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=99c3a6e264a74e983441b43550d2b7a816d4a8ea&newProject=try&newRevision=c055f823f201c747a3617b52e8f9ef4aeb35864f&framework=2&page=1&filter=installer+size
The right side is tip of my local repository, and the left side is backing out the patches for bug 1742933 from the right side's changeset. The result is:
osx-shippable 117,735,271.31 ± 0.02 > 117,721,641.96 ± 0.03 -0.01% 1.78 (low)
So indeed, my patches increases the binary size due to perhaps the lambdas, but it causes only the 2nd row's regression in comment 0. The first row is not caused by bug 1742933, could be an environment issue or other changesets.
Andra Esanu: What do you think?
|
|
Assignee | |
Comment 4•3 years ago
|
||
My patches will gets this result:
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=99c3a6e264a74e983441b43550d2b7a816d4a8ea&newProject=try&newRevision=ff40b41f5e560ee2a8118bb9740eaa89d01a4f3f&framework=2&page=1&filter=installer+size
So it looks like not affecting to the installer size of shippable build.
|
|
Assignee | |
Comment 5•3 years ago
|
||
(I wonder why the installer size built from same changeset is not same??)
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #3)
So indeed, my patches increases the binary size due to perhaps the lambdas, but it causes only the 2nd row's regression in comment 0. The first row is not caused by bug 1742933, could be an environment issue or other changesets.
Andra Esanu: What do you think?
The first regression row in comment 0 was generated on bug 1742933 for part 7 (ffb5b57840a1482615017676bb2cfb73c9fbb2a1).
There is another data point right before this one that is related to bug 1753364 (f689a5f94b9ab40fd6c06140e954bc668d14591e). It also had a push f4016ecd6f8ec145c73c6cece937b642284c7ff8 before bug 1742933's part 1.
Do you think bug 1753364 has a role in this?
|
|
Assignee | |
Comment 7•3 years ago
|
||
(In reply to Andra Esanu from comment #6)
The first regression row in comment 0 was generated on bug 1742933 for part 7 (ffb5b57840a1482615017676bb2cfb73c9fbb2a1).
There is another data point right before this one that is related to bug 1753364 (f689a5f94b9ab40fd6c06140e954bc668d14591e). It also had a push f4016ecd6f8ec145c73c6cece937b642284c7ff8 before bug 1742933's part 1.Do you think bug 1753364 has a role in this?
No, I don't think so, but it's really wired because of backing out not fixing the installer size completely...
|
|
Assignee | |
Comment 8•3 years ago
|
||
Capturing everything causes increasing the binary size especially of debug
build so that we should add more arguments to the callback and make some
lambda methods capture individual variables when they are necessary.
Note that nobody uses the 3rd argument, aPointToInsert, it'll be used to
fix bug 1759370 and makes the change smaller.
This decreases the size of xul.dll of debug build on Windows 123MB from 323MB.
I tried to delete all captures from the lambdas, but it does not affect to the
binary size and it makes the code harder to read, killing static analysis.
Therefore, we should not do it.
Depends on D141196
|
|
Assignee | |
Comment 9•3 years ago
|
||
This decreases the binary size of xul.dll of debug build on Windows 3K bytes.
Depends on D141447
|
||
Comment 10•3 years ago
|
||
|
||
Comment 11•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ce8667297823
https://hg.mozilla.org/mozilla-central/rev/d209d5f4d95e
Description
•