tree 2e3ccbad3eb9e22b0f103d5b08dfb9dca708ea58
parent ef23daf84df3f4df1f161dae9d6634e3656acf3b
author Primiano Tucci <primiano@google.com> 1535130652 +0200
committer Primiano Tucci <primiano@google.com> 1535130652 +0200

TraceProcesor: move from pull (BlobReader) to push architecture

So far the TraceProcessor was based on a pull architecture, where
the caller exposes a seekable pull interface (BlobReader) and the
TraceProcessor drives everything. This has two drawbacks:
- It's unnecessary: conversely to what we thought initially, we
  process the trace in one linear scan and never seek back.
- For the 'load from network' case, it requires to fully buffer
  the trace in JS/TS before passing that to the TP. This clearly
  doesn't work for big traces, both in terms of memory and
  latency.

This CL switches to a push model, where the caller simply calls
Parse(data, length) on the TP whenever a new trace chunk is
available (the caller doesn't have to care about boundaries).

This has the following advantages:
- Allows to get rid of a lot of complexity.
- Allows to directly stream chunks of the trace as they are
  loaded from the network. Not only this saves memory in the
  JS/TS engine, but also allows to hide the network latency
  because packets are parsed in a streaming fashion as they
  are received from the network.
- In the trace_processor_shell we can hide some I/O latencies
  in a similar fashion, by pre-fetching the next chunk while
  the trace processor is parsing the current one.
- Bump the trace_processor_shell performance to 450 MB/s.

Change-Id: I8192e83731daaffe9f3fe8e6344188de1adffbf3