[tracing] Fix, simplify and speed up accounting of TraceEvent memory overhead
commitb2ae97fb331cbad132a8e1aad9a25441fde75048
authorprimiano <primiano@chromium.org>
Thu, 23 Jul 2015 00:26:05 +0000 (22 17:26 -0700)
committerCommit bot <commit-bot@chromium.org>
Thu, 23 Jul 2015 00:27:02 +0000 (23 00:27 +0000)
treecaca082ea9814b743a9954134bc582acf2bc1d89
parent85432c82c466a62d6f56ee3d15def0affececa61
[tracing] Fix, simplify and speed up accounting of TraceEvent memory overhead

So far the accounting of TraceEvent memory overhead worked as follows:
 - Each TraceEvent keeps a cache of its own overhead.
 - The TraceBufferChunk (which is approx an array of 64 TraceEvent)
   keeps a cache of the all 64 TraceEvent, but only when completelly
   filled.

This is sub-optimal because:
 - There can be many TraceEvent(s), 10k-100k in a bulky 30s trace:
   when memory-infra is enabled, this causes a cost of several MB to
   keep the aforementioned per-TraceEvent caches.
 - Every time we have to estimate the size of a non-completely-full
   TraceBufferChunk, we still have to loop over their individual caches.
 - Least but not last, turns out that the current accounting is just
   wrong, as we ended up counting the sizeof(TraceEvent) both in
   TraceBufferChunk and in the individual TraceEvent.

This CL improves the situation as follows:
 - The per-TraceEvent cache is dropped. Much less memory is used.
 - The TraceBufferChunk still keeps a cache, but its cache is used in a
   smarter way and not just when it is full. We simply remember how many
   TraceEvent(s) we estimated in the previous pass and then estimate just
   the missing ones.
 - The double accounting issue is fixed, as now we count TraceEvent(s)
   only in TraceBufferChunk.

BUG=512383

Review URL: https://codereview.chromium.org/1251203003

Cr-Commit-Position: refs/heads/master@{#340005}
base/trace_event/trace_event_impl.cc
base/trace_event/trace_event_impl.h
base/trace_event/trace_event_memory_overhead.cc
base/trace_event/trace_event_memory_overhead.h