Bug 1354255 - Remove ElementRestyler::ComputeStyleChangeFor profiler instrumentation due to overhead. r?ehsan
This only has overhead if the profiler is running, but it means that it has
the potential to skew restyle times in profiles.
We haven't measured the overhead of this, but it's probably non-zero, and at
the moment our profiling efforts are more focused on getting accurate times
than on getting useful information about restyling cost sources.
MozReview-Commit-ID: 3KmiiyGrxZH
--- a/layout/base/GeckoRestyleManager.cpp
+++ b/layout/base/GeckoRestyleManager.cpp
@@ -3050,25 +3050,20 @@ ElementRestyler::ComputeStyleChangeFor(n
RestyleTracker& aRestyleTracker,
nsRestyleHint aRestyleHint,
const RestyleHintData& aRestyleHintData,
nsTArray<ContextToClear>&
aContextsToClear,
nsTArray<RefPtr<nsStyleContext>>&
aSwappedStructOwners)
{
+ PROFILER_LABEL("ElementRestyler", "ComputeStyleChangeFor",
+ js::ProfileEntry::Category::CSS);
+
nsIContent* content = aFrame->GetContent();
- std::string elemDesc;
- if (profiler_is_active() && content) {
- elemDesc = ToString(*content);
- }
-
- PROFILER_LABEL_DYNAMIC("ElementRestyler", "ComputeStyleChangeFor",
- js::ProfileEntry::Category::CSS,
- content ? elemDesc.c_str() : "<unknown>");
if (aMinChange) {
aChangeList->AppendChange(aFrame, content, aMinChange);
}
NS_ASSERTION(!aFrame->GetPrevContinuation(),
"must start with the first continuation");
// We want to start with this frame and walk all its next-in-flows,