Revert of [tracing] Fix, simplify and speed up accounting of TraceEvent memory overhead (patchset #4 id:60001 of https://codereview.chromium.org/1251203003/ )
Reason for revert:
Speculative revert for https://code.google.com/p/chromium/issues/detail?id=516056
Original issue's description:
> [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
>
> Committed: https://crrev.com/b2ae97fb331cbad132a8e1aad9a25441fde75048
> Cr-Commit-Position: refs/heads/master@{#340005}
TBR=dsinclair@chromium.org,primiano@chromium.org
BUG=512383
Review URL: https://codereview.chromium.org/1258903003
Cr-Commit-Position: refs/heads/master@{#341910}
CrOS-Libchrome-Original-Commit: 8f329fc15f5fa64f64308244266a304c122a2868
6 files changed