commit 8320e6d2b742e5ecde2c60ca535a1d3c8f4c0bdb
author Lalit Maganti <lalitm@google.com> Thu Mar 14 18:49:33 2019 +0000
committer Lalit Maganti <lalitm@google.com> Thu Mar 14 18:49:33 2019 +0000
tree edb9fdad183b59bf2ec912d1a811e7d694d22a8d
parent 29885798ac66d92369e98bc90a51ee2d2e497ec4

trace_processor: split up counters table

This CL splits up the counters table into two tables: counter_definitions
and counter_values. We also add a view to make the change transparent to
current callers so we don't need to change any users of trace processor.

This change should allow for more efficient queries
from the UI which only wants the definitions to be able to create the
tracks. Moreover, even on the counters view, if queries are done on name,
ref and ref type, we can do this a lot more efficiently on the definitions.

For example on a 80MB trace (b/124495829) with just memory counters
(i.e. no sched) and the following query (very similar to those done
both in the UI and in benchmarking metrics code)
select
  ts,
  lead(ts) over (partition by ref_type order by ts) as ts_end,
  value
from counters
where name = 'SwapCached' and ref = 0

we get the following performance numbers:
Old code: 263.902 ms
New code (using the view): 107.088 ms (2.46x speedup)

In query the UI does on startup (and called out in b/124495829):
select
  name,
  ref,
  ref_type
from counters
where ref is not null
group by ref, ref_type, name

we get the following performance numbers:
Old code: 11020.611 ms
New code (using the view): 29076.535 ms (2.63x slow down)
New code (directly querying counter_definitions): 48.554 ms (226x speedup)

A follow up CL will further improve the speed of the join operation in view
and filters in general significantly.

Bug: 124495829
Change-Id: I57cf1be328364d53bd6e65eeb4434d015df86981