New issue
Advanced search Search tips

Issue 807320 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

Long tryjob for fuchsia x64

Project Member Reported by scottmg@chromium.org, Jan 30 2018

Issue description

from jam:

http://build.chromium.org/p/tryserver.chromium.linux/builders/fuchsia_x64/builds/59416

43 minutes seems slow to compile. and 12 minutes while running content_unittests is odd. does this run slower than chrome linux? if so, perhaps we can adjust sharding level?

re compile, are unnecessary symbols being generated?



 

Comment 1 by w...@chromium.org, Jan 30 2018

Re compile-time: We may be suffering due to building the whole of Blink twice, to support V8 snapshots (once for the Linux 'host' platform, once for the Fuchsia 'target'); I'll look into that.

Re run-time: Yes, we tend to see a 10x slow-down running tests with the extra layer of emulation (since the bot currently has to run Fuchsia in QEMU on Linux on the bot, rather than Fuchsia directly on the bot). We're investigating why the slow-down is so severe. Increasing sharding may be a reasonable compromise in the meantime.
Oh, yeah, I forgot about that Blink change! I do see e.g.

[119/24415] CXX obj/third_party/WebKit/Source/platform/wtf/wtf/PrintStream.o
[4643/24196] CXX clang_x64/obj/third_party/WebKit/Source/platform/wtf/wtf/PrintStream.o

which is definitely making things more expensive.

Comment 3 by w...@chromium.org, Jan 30 2018

Re compile-time: Confirmed that v8_use_snapshot increases the number of ninja build steps for content_unittests from ~24k to ~40k. There was discussion on the mailing list about restricting v8_use_snapshot to non-cross-builds for that reason - sounds like we should go ahead and do that.
After a bit of poking, I believe it's use_v8_context_snapshot rather than v8_use_snapshot. I'll send a CL to disable that on Fuchsia for now, as I don't think we're getting much/any upside in exchange for quite a bit longer builds.

Comment 5 by w...@chromium.org, Jan 30 2018

Re #4: Yeah, use_v8_context_snapshot in the Chromium tree looks to drop the build steps from ~44k to ~29k; I think the gain from disabling v8_use_snapshot was largely from implicitly also disabling use_v8_context_snapshot. :P
Project Member

Comment 6 by bugdroid1@chromium.org, Jan 30 2018

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

commit b821ff139a2b962d444eb1fd162407650fc2a45c
Author: Scott Graham <scottmg@chromium.org>
Date: Tue Jan 30 19:29:02 2018

fuchsia: Disable use_v8_context_snapshot

Causing extra long compiles, and is currently of limited utility on
Fuchsia. We might want to investigate the runtime performance delta for
this feature once more complex JS is running on Fuchsia.

Bug: 764576, 807320
Change-Id: Iefee81a7e9078b42b68766f6891bbed2233a6599
Reviewed-on: https://chromium-review.googlesource.com/893427
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532989}
[modify] https://crrev.com/b821ff139a2b962d444eb1fd162407650fc2a45c/tools/v8_context_snapshot/v8_context_snapshot.gni

Comment 7 by w...@chromium.org, Jan 31 2018

Regarding the time spent running the unit-tests, it seems that virtualization overhead bites us especially badly because we run multi-core; we could switch to single-core plus sharding, but that will require some changes to the TestLauncher, e.g. to support filters in single-job mode.
Cc: scottmg@chromium.org
Owner: ----
Status: Available (was: Assigned)
Status: Untriaged (was: Available)
Available, but no owner or component? Please find a component, as no one will ever find this without one.

Sign in to add a comment