Closed Bug 1707508 Opened 5 years ago Closed 5 years ago

0.14 - 0.1% installer size / installer size (OSX) regression on Tue April 20 2021

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Version:
Firefox 90
Type:
defect

Tracking

(firefox-esr78 unaffected, firefox88 unaffected, firefox89 unaffected, firefox90 affected)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox88 --- unaffected
firefox89 --- unaffected
firefox90 --- affected

People

(Reporter: alexandrui, Assigned: mhentges)

References

(Regression)

Details

(Keywords: perf-alert, regression)

Perfherder has detected a build_metrics performance regression from push 630f37b668d88d30886d42c76e76ee0bef0afd0a. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio Suite Test Platform Options Absolute values (old vs new)
0.14% installer size osx-shippable instrumented 114,720,234.29 -> 114,876,836.50
0.10% installer size osx-shippable instrumented 114,761,658.12 -> 114,880,481.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.

This is regressed by Bug 1602862.

Component: Performance → General
Product: Testing → Firefox Build System
Assignee: nobody → mhentges
Status: NEW → ASSIGNED

:mhentges please change the product and component of the bug to the relevant ones as I don't have access to the bug that caused this regression.

Flags: needinfo?(mhentges)
Regressed by: 1602862
Has Regression Range: --- → yes

I'm not sure that Bug 1602862 actually regresses this.
I'll re-adjust references as needed when I investigate this regression.

The size difference stems entirely from an extra ~125Ki in Contents/MacOS/XUL:

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.1% +62.1Ki  +0.1% +62.1Ki    String Table
  +0.3% +19.8Ki  +0.3% +19.8Ki    __DATA,__llvm_prf_names
  +0.1% +18.5Ki  +0.1% +18.5Ki    __DATA,__llvm_prf_data
  +0.1% +17.3Ki  +0.1% +17.3Ki    __DATA,__llvm_prf_cnts
  +0.2% +14.0Ki  +0.2% +14.0Ki    Symbol Table
  +4.3% +2.63Ki  +4.3% +2.63Ki    [__TEXT]
  +0.1% +1.03Ki  +0.1% +1.03Ki    __TEXT,__unwind_info
  +0.1%    +808  +0.1%    +808    Rebase Info
  +0.1%    +648  +0.1%    +648    Function Start Addresses
  +0.0%    +352  +0.0%    +352    __TEXT,__cstring
  +0.0%     +64  +0.0%     +64    __DATA,__const
  +0.0%     +24  +0.0%     +24    Table of Non-instructions
  -0.0%      -8  -0.0%      -8    __TEXT,__gcc_except_tab
  -0.1% -1.63Ki  -0.1% -1.63Ki    __DATA,__llvm_prf_vals
  -0.1% -4.50Ki  -0.1% -4.50Ki    __DATA,__llvm_prf_vnds
 -24.1% -5.57Ki -22.2% -5.57Ki    [__DATA]
  +0.0%  +125Ki  +0.0%  +125Ki    TOTAL

I wouldn't doubt that this is due to the new MOZ_DIAGNOSTIC_ASSERT calls in the commonly-used nsTSubstring class.
This seems like an acceptable size regression to me.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(mhentges)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.