diff options
author | David Teller <dteller@mozilla.com> | 2019-01-29 03:11:39 +0100 |
---|---|---|
committer | wolfbeast <mcwerewolf@wolfbeast.com> | 2019-01-29 03:11:39 +0100 |
commit | b55d41c240df13812760a2a77f086a477f450fd0 (patch) | |
tree | 4e9e254e74b4cbf4cfafa07a37db8af192883925 /toolkit/components/perfmonitoring | |
parent | abcaa560fcaf2f814fc40eef46557033c910eb96 (diff) | |
download | UXP-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/perfmonitoring')
-rw-r--r-- | toolkit/components/perfmonitoring/nsPerformanceStats.cpp | 11 | ||||
-rw-r--r-- | toolkit/components/perfmonitoring/nsPerformanceStats.h | 2 |
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 |