Closed Bug 1647780 Opened 4 months ago Closed 3 months ago

9MB GeckoView size increase

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(firefox-esr68 unaffected, firefox-esr78 wontfix, firefox79 wontfix, firefox80 wontfix, firefox81 fixed)

RESOLVED FIXED
81 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- fixed

People

(Reporter: agi, Assigned: glandium)

References

(Regressed 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [geckoview])

Attachments

(1 file)

Flags: needinfo?(mh+mozilla)
Summary: 9MB GeckoView size increase after Bug 1640578 → 9MB GeckoView size increase

I think this is essentially a dup of bug 1644553 -- or at least will be addressed by the patch in that bug.

Whiteboard: [geckoview]
Severity: -- → S3
Priority: -- → P3

S3/P3 on a 18% regression on libxul size for mobile apps? How about reconsidering that?

Before this change libxul size 46,056,749 bytes after this regression libxul size 54,248,458 bytes.

Flags: needinfo?(rstewart)

I don't think the condescension is appropriate or constructive.

We're waiting on a NI from someone who isn't in an American timezone. The bug will be resolved.

Flags: needinfo?(rstewart)

(In reply to Nathan Froyd [:froydnj] from comment #1)

I think this is essentially a dup of bug 1644553 -- or at least will be addressed by the patch in that bug.

Wrong bug?

Flags: needinfo?(mh+mozilla)

It appears we were stripping local symbols in libraries before bug 1640578, which was actually an oversight from bug 818418: it wasn't actually intended that Android would be excluded. We do strip more fully when profiling is not enabled. Profiling is only enabled on central, not beta/release/esr. So unless it turns into a regression in beta, I'd call this wontfix.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WONTFIX

(In reply to Mike Hommey [:glandium] from comment #5)

It appears we were stripping local symbols in libraries before bug 1640578, which was actually an oversight from bug 818418: it wasn't actually intended that Android would be excluded. We do strip more fully when profiling is not enabled. Profiling is only enabled on central, not beta/release/esr. So unless it turns into a regression in beta, I'd call this wontfix.

Hey glandium, thanks for looking at this. Why do we have symbols on Android Nightlies? I thought we didn't use them for anything.

Flags: needinfo?(mh+mozilla)

(In reply to Mike Hommey [:glandium] from comment #4)

(In reply to Nathan Froyd [:froydnj] from comment #1)

I think this is essentially a dup of bug 1644553 -- or at least will be addressed by the patch in that bug.

Wrong bug?

I think I somehow assumed that profile generation had been turned on for artifact builds and we were therefore grabbing the wrong libxul. But that's not even the scenario described by the bug, so chalk that one up to my own confusion. :)

(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #6)

(In reply to Mike Hommey [:glandium] from comment #5)

It appears we were stripping local symbols in libraries before bug 1640578, which was actually an oversight from bug 818418: it wasn't actually intended that Android would be excluded. We do strip more fully when profiling is not enabled. Profiling is only enabled on central, not beta/release/esr. So unless it turns into a regression in beta, I'd call this wontfix.

Hey glandium, thanks for looking at this. Why do we have symbols on Android Nightlies? I thought we didn't use them for anything.

They're useful for, among other things, the profiler.

Flags: needinfo?(mh+mozilla)

(In reply to Mike Hommey [:glandium] from comment #8)

They're useful for, among other things, the profiler.

Do the symbols have to be in the device? could we make desktop download the symbols when using the profiler instead? 9MB of extra APK size (even if only for the nightly browser) is not something we should take lightly, especially for a developer-only feature like the profiler.

Flags: needinfo?(mh+mozilla)

Reopening until Comment 9 gets addressed.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Upon reflection, we probably don't need the extra symbols anymore. Back
when we reduced the amount of stripping when enabling profiling, the
profiler wasn't able to download symbols on its own. It now is able to
do so, on all platforms.

As the stripping happens at packaging time, this doesn't change anything
for mach run on local builds.

Assignee: nobody → mh+mozilla
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/f849afa84d90
Don't strip less when profiling is enabled. r=froydnj
Status: REOPENED → RESOLVED
Closed: 4 months ago3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch

IIUC, this doesn't affect the builds we actually end up shipping and therefore doesn't need backporting. Please let me know if I'm misunderstanding, though!

You're completely right. It only affects nightly.

Flags: needinfo?(mh+mozilla)
Regressions: 1659452

(In reply to Mike Hommey [:glandium] from comment #11)

Upon reflection, we probably don't need the extra symbols anymore. Back
when we reduced the amount of stripping when enabling profiling, the
profiler wasn't able to download symbols on its own. It now is able to
do so, on all platforms.

The Gecko profiler is able to find the symbols, yes, but native profilers like Instruments and Activity Monitor are not. We use those profilers when we run into limitations with the Gecko profiler, for example for problems with high CPU usage. We often ask users who report high CPU usage on macOS to capture a sample with Activity Monitor from Nightly, and those had useful symbols in the past.

Could we undo this change for macOS?

Flags: needinfo?(agi)
Flags: needinfo?(agi) → needinfo?(mh+mozilla)
Regressions: 1665013
Regressions: 1667170

I filed bug 1667170 about the macOS regression.

Flags: needinfo?(mh+mozilla)
You need to log in before you can comment on or make changes to this bug.