I suspect that this is the "v8 tracing metrics taking too long" bug again. Lemme try to reproduce this bug locally

It would be taking me sometimes to get a windows laptop working. 
I run the test locally on Linux & can confirm that it takes very long to process a v8 trace in browsing desktop benchmark.

Also the log in https://chromium-swarm.appspot.com/task?id=3bd9efc48132dc10&refresh=10&show_raw=1 shows that the tracing size right before the task was killed is 748647426 bytes = 748.647426 Mb

Based on those two, I highly suspect that this is the problem with v8 trace becoming too big, hence taking too long to process.

In the previous passing build (https://chromium-swarm.appspot.com/task?id=3bd448c53565dd10&refresh=10&show_raw=1), the trace size of browse:news:cnn was just ~300 mb. So something in v8 has caused the trace size to blow up to 700 mb recently.

I have some plan to mitigate this kind of problem, will write a doc about this soon.

Could this be related to crbug/813824. I think gab@ has added more fine grained trace events. I think this got reverted. 

The following revision refers to this bug:
  https://chromium.googlesource.com/catapult/+/f9b01a0935b68f998c553b13185a67b4a1f30f27

commit f9b01a0935b68f998c553b13185a67b4a1f30f27
Author: Nghia Nguyen <nednguyen@google.com>
Date: Sat Feb 24 21:18:05 2018

Add logging of when tracing metrics computation started

Bug: chromium:812631
Change-Id: If01e970f5f76562da56b5f21e581bc1e5fb332eb
Reviewed-on: https://chromium-review.googlesource.com/934629
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Reviewed-by: Charlie Andrews <charliea@chromium.org>

[modify] https://crrev.com/f9b01a0935b68f998c553b13185a67b4a1f30f27/telemetry/telemetry/web_perf/timeline_based_measurement.py

The following revision refers to this bug:
  https://chromium.googlesource.com/catapult/+/113761866173daed9a965975e991c57749e2cd1c

commit 113761866173daed9a965975e991c57749e2cd1c
Author: Nghia Nguyen <nednguyen@google.com>
Date: Tue Feb 27 09:53:08 2018

[Telemetry] Cap the limit of trace size in TimelineBasedMeasurement to 400 MiB


Occasionally, we have benchmark which has one or two stories in which the trace
size is exceptionally big, which cause I/O timeout for the whole benchmark due
to tracing computation taking too long (see attached bug). This CL makes sure
that TimelineBasedMeasurement fails early on traces that are too big. This
helps:
  1) Avoid I/O timeout, thus making failure of one story not affecting others.
  2) Make it easy to bisect the failure
  3) Make telemetry able to keep running, allowing archiving the trace files
    in cloud storage which makes later debugging easier.
  4) Make it's clearer what the errors are

In a passing run of v8.browsing_desktop, the trace size of browse:news:cnn story
is 150 mb (see log: https://chromium-swarm.appspot.com/task?id=3be98dbf0ec38e10&refresh=10&show_raw=1)

In a failing run, the trace size of that story is 750 MiB (https://chromium-swarm.appspot.com/task?id=3bd9efc48132dc10&refresh=10&show_raw=1)

We cap the trace limit to 400 MiB to ensure a reasonable time limit when
processing traces later.

Bug: chromium:812631
Change-Id: I36d027a4d4082c3eeae6623fd068f9029f46e792
Reviewed-on: https://chromium-review.googlesource.com/937063
Commit-Queue: Juan Antonio Navarro Pérez <perezju@chromium.org>
Reviewed-by: Charlie Andrews <charliea@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>

[modify] https://crrev.com/113761866173daed9a965975e991c57749e2cd1c/telemetry/telemetry/web_perf/timeline_based_measurement.py

@#4-5: yes the blow up was caused by fine grain events added for crbug.com/813824. Reverted already.