A suspect CL in the regression range is a V8 roll: https://codereview.chromium.org/2041373002

To reproduce this failure, download the latest Linux_x64 build from https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/ into $HOME/Downloads, and while cd'd into a Chromium workspace:

./content/test/gpu/run_gpu_test.py webgl_conformance --browser=exact --browser-executable=$HOME/Downloads/chrome-linux/chrome --webgl-conformance-version=2.0.0 --webgl2-only=true --story-filter=deqp_functional_gles3_vertexarrays

It looks like the time this test takes to run more than doubled with the recent V8 roll. While this test is certainly too large and should be split up, the time increase sounds like an unintended and potentially serious performance regression.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/42947e24de37b28e80c8456fdf36460c5296db63

commit 42947e24de37b28e80c8456fdf36460c5296db63
Author: geofflang <geofflang@chromium.org>
Date: Wed Jun 08 00:17:36 2016

Temporarily fail the deqp_functional_gles3_vertexarrays test on linux.

BUG= 618139 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
NOTRY=true

Review-Url: https://codereview.chromium.org/2048623003
Cr-Commit-Position: refs/heads/master@{#398431}

[modify] https://crrev.com/42947e24de37b28e80c8456fdf36460c5296db63/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py

Locally I cannot spot much of a difference with profiling.
There are only two CLs that could alter the behavior of the test in the given range.

1. https://codereview.chromium.org/2044843002 
2. https://codereview.chromium.org/2024833002

1. is essentially a refactoring which should not trigger any regressions (over all we do less work), our internal benchmark seem to confirm this.
No 2. changes the gn configuration which would be the prime suspect on v8-side here.

Could it be that accidentally slow checks/debug builds were enabled?

Ah. It certainly seems plausible that dcheck_always_on was broken in V8 when built with GN, and that fixing this slowed down execution.

Thanks for tracking this down. Let's close this as WontFix. We will split up this test soon anyway.