Closed Bug 1053188 Opened 10 years ago Closed 10 years ago

PGO memory has dropped 97.5% since August 11

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla34

People

(Reporter: froydnj, Assigned: mshal)

References

Details

dev-tree-management got this fascinating email recently: Improvement: Mozilla-Inbound - LibXUL Memory during link - WINNT 5.2 - 97.5% decrease And an accompanying graph to show that it seems to be sticking: http://graphs.mozilla.org/graph.html#tests=[[205,63,8]]&sel=1407702635000,1407875435000&displayrange=7&datatype=running Mozilla-Central shows the decrease for the PGO build: https://tbpl.mozilla.org/?rev=7fc96293ada8 The pushlog range is: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a663f207d55a&tochange=cd9c422f6bda Bug 1047621 looks like the only really likely build change, although it's possible one of the code changes could have magically shaved several GB off PGO memory usage...
Did we see any perf regressions? Usually when we've seen something like this it means "we broke things and aren't actually compiling with PGO".
Oh, actually, yeah, bug 1047621 broke the measurement. link.py works by calling Windows APIs to measure the memory usage of the process it's wrapping. Now that it's calling expandlibs_exec, all it's measuring is the memory usage of the Python process...
Bug 1047621 has been backed out for now.
Yeah, if only reducing the the PGO linker memory usage were *that* easy. :P
https://hg.mozilla.org/mozilla-central/rev/dd3712012832
Assignee: nobody → mshal
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
QA Whiteboard: [qa-]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.