New issue
Advanced search Search tips

Issue 713283 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , All
Pri: 3
Type: Feature



Sign in to add a comment

Explore parallelizing individual change file upload to speed overall change upload time.

Project Member Reported by wkorman@chromium.org, Apr 19 2017

Issue description

Explore parallelizing the upload of a change with a large number of baselines. I have no idea what the current implementation or technical hurdles might be, but I had a (comparatively not huge, but larger than normal) change with maybe a few hundred baselines and I had to upload 2x and I had to wait and watch it upload one file at a time serially taking maybe 3 - 5s each, so across all devs, the upside on time savings seems high.

Note I was not uploading to gerrit and I certainly support only scoping/pursuing work for gerrit. Maybe the situation is better there?

https://codereview.chromium.org/2820743003/ and log sample attached. Some changes from Layout/Paint team members on occasion include thousands of baselines.
 
log.txt
93.6 KB View Download
Cc: tandrii@chromium.org
Components: Infra>Codereview>Gerrit
What would this involve? -- is it the case that git cl uploads to gerrit by invoking `git push`?

Possibly related part of git cl:
https://cs.chromium.org/chromium/tools/depot_tools/git_cl.py?l=2990
Status: WontFix (was: Untriaged)
For Rietveld, afair there is already concurrency, but it's limited to avoid ddos-ing rietveld.

For Gerrit, it's pushing git objects already, as qyearsley@ rightly noted. Gerrit is so far limited dogfood, so consider asking agable@ to sign up your sub-team :)

There are still parts in git cl that might not work as fast as they could, so we'd love to know how it works for you on huge changes.

Sign in to add a comment