Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1713993002:
[Swarming] Speed up test262 upload/download. (Closed)
|
Created:
4 years, 10 months ago by Michael Achenbach Modified:
4 years, 10 months ago CC:
v8-reviews_googlegroups.com, M-A Ruel Base URL:
https://chromium.googlesource.com/v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
Description[Swarming] Speed up test262 upload/download.
This experimentally implements taring/untaring the test data
for test262 on the v8-side before test isolation and when
running the tests.
It archives on demand only if the tar is outdated compared
to the contained files. This comes with a cost of ~1s extra
to run gyp on linux and ~6s extra on windows. Ninja is
lightning fast afterwards in detecting changes. Also, we
archive only when test_isolation_mode is set and when
the test262_run target is required.
The archiving itself costs ~30s on all platforms. But as the
files will change seldom this shouldn't have a big impact.
Extraction on the test runner side is below 2s on mac and
linux. The speedup is enormous. Around 5 minutes were spent
on download on swarming slaves before, which is now only
a few seconds. So total test time for release (no variants),
e.g. goes from 8 to 3 minutes.
BUG=chromium:535160
LOG=n
Committed: https://crrev.com/6cecb3eb7717e8355beb38b4e866de359ea09d07
Cr-Commit-Position: refs/heads/master@{#34155}
Patch Set 1 #Patch Set 2 : Fixes #Patch Set 3 : Fixes #
Total comments: 3
Patch Set 4 : Fix /\ #
Messages
Total messages: 32 (17 generated)
The CQ bit was checked by machenbach@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1713993002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1713993002/1
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win64_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/3181)
The CQ bit was checked by machenbach@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1713993002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1713993002/20001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/...) v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/...) v8_linux64_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/1636) v8_linux_dbg_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/1637) v8_linux_gcc_compile_rel on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...) v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...) v8_linux_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/1633)
The CQ bit was checked by machenbach@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1713993002/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1713993002/40001
Description was changed from ========== [Swarming] Speedup test262 upload/download. BUG= ========== to ========== [Swarming] Speedup test262 upload/download. BUG=chromium:535160 LOG=n ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== [Swarming] Speedup test262 upload/download. BUG=chromium:535160 LOG=n ========== to ========== [Swarming] Speedup test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on linux and ~70s on windows. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ==========
machenbach@chromium.org changed reviewers: + jkummerow@chromium.org, tandrii@chromium.org
PTAL. I don't have numbers for the speedup on windows as we don't run test262 anymore on the tryservers (because of the slowness I'm trying to fix here). So we'll get numbers from CI once this lands. If the results are super-awesome, and somebody moves this logic into swarming/isolate code, I'll remove it here again.
https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py File test/test262/archive.py (right): https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py... test/test262/archive.py:12: return None if tar_info.name.startswith('data/.git') else tar_info hmm - wondering if this is a \ on windows and it tars the .git folder... would explain why it's so slow...
Description was changed from ========== [Swarming] Speedup test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on linux and ~70s on windows. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ========== to ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on linux and ~70s on windows. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ==========
lgtm https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py File test/test262/archive.py (right): https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py... test/test262/archive.py:12: return None if tar_info.name.startswith('data/.git') else tar_info On 2016/02/19 14:02:49, Michael Achenbach wrote: > hmm - wondering if this is a \ on windows and it tars the .git folder... would > explain why it's so slow... well you can definitely test for both here.
The CQ bit was checked by machenbach@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1713993002/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1713993002/60001
https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py File test/test262/archive.py (right): https://codereview.chromium.org/1713993002/diff/40001/test/test262/archive.py... test/test262/archive.py:12: return None if tar_info.name.startswith('data/.git') else tar_info On 2016/02/19 14:12:50, tandrii(chromium) wrote: > On 2016/02/19 14:02:49, Michael Achenbach wrote: > > hmm - wondering if this is a \ on windows and it tars the .git folder... would > > explain why it's so slow... > > well you can definitely test for both here. Using os.path.join here now. It indeed caused the windows slowness. Now windows takes only 30s instead of 70s. I'll update the CL description.
Description was changed from ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on linux and ~70s on windows. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ========== to ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on all platforms. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ==========
The CQ bit was unchecked by machenbach@chromium.org
The CQ bit was checked by machenbach@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tandrii@chromium.org Link to the patchset: https://codereview.chromium.org/1713993002/#ps60001 (title: "Fix /\")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1713993002/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1713993002/60001
lgtm
Message was sent while issue was closed.
Description was changed from ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on all platforms. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ========== to ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on all platforms. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001)
Message was sent while issue was closed.
Description was changed from ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on all platforms. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n ========== to ========== [Swarming] Speed up test262 upload/download. This experimentally implements taring/untaring the test data for test262 on the v8-side before test isolation and when running the tests. It archives on demand only if the tar is outdated compared to the contained files. This comes with a cost of ~1s extra to run gyp on linux and ~6s extra on windows. Ninja is lightning fast afterwards in detecting changes. Also, we archive only when test_isolation_mode is set and when the test262_run target is required. The archiving itself costs ~30s on all platforms. But as the files will change seldom this shouldn't have a big impact. Extraction on the test runner side is below 2s on mac and linux. The speedup is enormous. Around 5 minutes were spent on download on swarming slaves before, which is now only a few seconds. So total test time for release (no variants), e.g. goes from 8 to 3 minutes. BUG=chromium:535160 LOG=n Committed: https://crrev.com/6cecb3eb7717e8355beb38b4e866de359ea09d07 Cr-Commit-Position: refs/heads/master@{#34155} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/6cecb3eb7717e8355beb38b4e866de359ea09d07 Cr-Commit-Position: refs/heads/master@{#34155} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
