Change deque to vector in the critical path
Profiling indicates that the deque accesses for strings and processes are on the critical path
- even though they are O(1) they have a greater fixed size cost compared to a simple vector
(they cost ~4 minutes on a ~30 minute trace query execution).
Changing them to vector greatly speeds this up. The cost of growing vector capacity only
needs to paid once and is relatively cheap (relatively small expected size for these arrays).
If the string pool is also expected to grow indefinitely (e.g. args or logcat) perhaps we should
consider using different pools per case.
Bug: b/128355350
Change-Id: I5c56049297a49b73a15448c9202346a97890b2ba
diff --git a/src/trace_processor/trace_storage.h b/src/trace_processor/trace_storage.h
index 22a3427..ca942db 100644
--- a/src/trace_processor/trace_storage.h
+++ b/src/trace_processor/trace_storage.h
@@ -610,7 +610,7 @@
const RawEvents& raw_events() const { return raw_events_; }
RawEvents* mutable_raw_events() { return &raw_events_; }
- const std::deque<std::string>& string_pool() const { return string_pool_; }
+ const std::vector<std::string>& string_pool() const { return string_pool_; }
// |unique_processes_| always contains at least 1 element becuase the 0th ID
// is reserved to indicate an invalid process.
@@ -644,13 +644,15 @@
Args args_;
// One entry for each unique string in the trace.
- std::deque<std::string> string_pool_;
+ std::vector<std::string> string_pool_;
// One entry for each unique string in the trace.
std::unordered_map<StringHash, StringId> string_index_;
// One entry for each UniquePid, with UniquePid as the index.
- std::deque<Process> unique_processes_;
+ // Never hold on to pointers to Process, as vector resize will
+ // invalidate them.
+ std::vector<Process> unique_processes_;
// One entry for each UniqueTid, with UniqueTid as the index.
std::deque<Thread> unique_threads_;