PGO has very few profile data on incremental builds - NSPR part

RESOLVED FIXED in 4.9

Status

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

(Blocks: 1 bug)

other
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

7 years ago
+++ This bug was initially created as a clone of Bug #676252 +++

We don't rebuild the objects that are already in the objdir, and they are final objects, not ones with instrumentation... (doh)

So we end up running the profile without instrumentation in most object files.

The easy solution would be to clobber before the profile generate pass, but that would be a huge waste of time. I think an easy way to avoid this problem, while keeping fast(ish) builds is to change the object file extension in one of the passes so that we effectively never overwrite object files from the profile generate pass in the profile use pass. That would double disk usage for object files, though.

On the other hand, we could probably skip debugging symbols in the profile generate pass, which would make the object files smaller. (though they might be useful in the case running firefox for the profile crashes)
(Assignee)

Comment 1

7 years ago
Created attachment 551434 [details] [diff] [review]
Use a different object file extension for the first PGO build pass with GCC. NSPR part
Attachment #551434 - Flags: review?(ted.mielczarek)
(Assignee)

Updated

7 years ago
Assignee: wtc → mh+mozilla

Updated

7 years ago
Target Milestone: --- → 4.9
Comment on attachment 551434 [details] [diff] [review]
Use a different object file extension for the first PGO build pass with GCC. NSPR part

Review of attachment 551434 [details] [diff] [review]:
-----------------------------------------------------------------

::: nsprpub/config/config.mk
@@ +177,5 @@
>  RELEASE_LIB_DIR = $(RELEASE_DIR)/$(BUILD_NUMBER)/$(OBJDIR_NAME)/lib
> +
> +ifdef MOZ_PROFILE_GENERATE
> +ifdef NS_USE_GCC
> +OBJ_SUFFIX := i_o

As with the other patch, this could stand a comment.
Attachment #551434 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 3

7 years ago
Created attachment 553398 [details] [diff] [review]
Use a different object file extension for the first PGO build pass with GCC. NSPR part

Updated with a comment. Ted, could you land this on nspr?
(Assignee)

Updated

7 years ago
Attachment #551434 - Attachment is obsolete: true
(Assignee)

Comment 4

7 years ago
Created attachment 554315 [details] [diff] [review]
Use a different object file extension for the first PGO build pass with GCC. NSPR part
Attachment #554315 - Flags: review?(ted.mielczarek)
(Assignee)

Updated

7 years ago
Attachment #553398 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Blocks: 659311
Comment on attachment 554315 [details] [diff] [review]
Use a different object file extension for the first PGO build pass with GCC. NSPR part

Review of attachment 554315 [details] [diff] [review]:
-----------------------------------------------------------------

::: nsprpub/config/rules.mk
@@ +381,5 @@
> +ifdef NS_USE_GCC
> +# Force rebuilding libraries and programs in both passes because each
> +# pass uses different object files.
> +$(PROGRAM) $(SHARED_LIBRARY) $(LIBRARY): pgo.relink
> +.PHONY: pgo.relink

I think I'd prefer if you used FORCE here, since we use that in the Moz build system, and pgo.relink is used as an actual file on Windows.
Attachment #554315 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 6

7 years ago
Please feel free to change that when you land it on NSPR.
Checking in config/autoconf.mk.in;
/cvsroot/mozilla/nsprpub/config/autoconf.mk.in,v  <--  autoconf.mk.in
new revision: 1.44; previous revision: 1.43
done
Checking in config/config.mk;
/cvsroot/mozilla/nsprpub/config/config.mk,v  <--  config.mk
new revision: 3.35; previous revision: 3.34
done
Checking in config/rules.mk;
/cvsroot/mozilla/nsprpub/config/rules.mk,v  <--  rules.mk
new revision: 3.83; previous revision: 3.82
done
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Depends on: 683861
You need to log in before you can comment on or make changes to this bug.