summaryrefslogtreecommitdiffstats
path: root/toolkit/components
diff options
context:
space:
mode:
authorDavid Teller <dteller@mozilla.com>2019-01-29 03:11:39 +0100
committerwolfbeast <mcwerewolf@wolfbeast.com>2019-01-29 03:11:39 +0100
commitb55d41c240df13812760a2a77f086a477f450fd0 (patch)
tree4e9e254e74b4cbf4cfafa07a37db8af192883925 /toolkit/components
parentabcaa560fcaf2f814fc40eef46557033c910eb96 (diff)
downloadUXP-b55d41c240df13812760a2a77f086a477f450fd0.tar
UXP-b55d41c240df13812760a2a77f086a477f450fd0.tar.gz
UXP-b55d41c240df13812760a2a77f086a477f450fd0.tar.lz
UXP-b55d41c240df13812760a2a77f086a477f450fd0.tar.xz
UXP-b55d41c240df13812760a2a77f086a477f450fd0.zip
Reduce number of allocations in AutoStopwatch
This patch fixes two related issues. 1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to communicate with its callback during each compartment switch. This vector was designed to allow its contents to be stack-allocated but they turned out to be accidentally heap-allocated. 2. During each tick, the stopwatch fills a vector `recentGroups_`. This vector always started with minimal capacity and had to grow repeatedly as groups were added, causing repeated reallocations. This patch preallocates `recentGroups_` to have the same capacity as the previous tick. We expect that this should eventually reach a stable size that closely matches the actual needs of the process.
Diffstat (limited to 'toolkit/components')
-rw-r--r--toolkit/components/perfmonitoring/nsPerformanceStats.cpp11
-rw-r--r--toolkit/components/perfmonitoring/nsPerformanceStats.h2
2 files changed, 10 insertions, 3 deletions
diff --git a/toolkit/components/perfmonitoring/nsPerformanceStats.cpp b/toolkit/components/perfmonitoring/nsPerformanceStats.cpp
index 6c470356a..59d84ced1 100644
--- a/toolkit/components/perfmonitoring/nsPerformanceStats.cpp
+++ b/toolkit/components/perfmonitoring/nsPerformanceStats.cpp
@@ -1082,6 +1082,9 @@ nsPerformanceStatsService::GetPerformanceGroups(JSContext* cx,
return false;
}
+ // Returning a vector that is too large would cause allocations all over the
+ // place in the JS engine. We want to be sure that all data is stored inline.
+ MOZ_ASSERT(out.length() <= out.sMaxInlineStorage);
return true;
}
@@ -1310,8 +1313,12 @@ nsPerformanceStatsService::GetResources(uint64_t* userTime,
void
nsPerformanceStatsService::NotifyJankObservers(const mozilla::Vector<uint64_t>& aPreviousJankLevels) {
- GroupVector alerts;
- mPendingAlerts.swap(alerts);
+
+ // The move operation is generally constant time, unless
+ // `mPendingAlerts.length()` is very small, in which case it's fast anyway.
+ GroupVector alerts(Move(mPendingAlerts));
+ mPendingAlerts = GroupVector(); // Reconstruct after `Move`.
+
if (!mPendingAlertsCollector) {
// We are shutting down.
return;
diff --git a/toolkit/components/perfmonitoring/nsPerformanceStats.h b/toolkit/components/perfmonitoring/nsPerformanceStats.h
index 6902c840d..661a78a1a 100644
--- a/toolkit/components/perfmonitoring/nsPerformanceStats.h
+++ b/toolkit/components/perfmonitoring/nsPerformanceStats.h
@@ -19,7 +19,7 @@
class nsPerformanceGroup;
class nsPerformanceGroupDetails;
-typedef mozilla::Vector<RefPtr<nsPerformanceGroup>> GroupVector;
+typedef mozilla::Vector<RefPtr<nsPerformanceGroup>, 8> GroupVector;
/**
* A data structure for registering observers interested in