| 1 |
On Wed, 18 Jan 2017 10:48:18 +0100 |
| 2 |
Dirkjan Ochtman <djc@g.o> wrote: |
| 3 |
|
| 4 |
> This doesn't ring intuitively true for me. Maybe you're talking about |
| 5 |
> running a "repoman full" for every committed package; I'm not. The |
| 6 |
> checks Doug describes are all package-local. What makes this process |
| 7 |
> so expensive? |
| 8 |
|
| 9 |
Even on a per-package basis it can be expensive, and how expensive it is |
| 10 |
gets worse the more dependencies you have. |
| 11 |
|
| 12 |
And its really not worth it to me to penalise every developer with that overhead |
| 13 |
on every push simply because a subset of the developers don't want to execute that code locally. |
| 14 |
|
| 15 |
That seems like trading decentralised effort for a centralised and shared bottleneck. |
| 16 |
|
| 17 |
As it was, I had a push today take more than 15 seconds and I started to worry something was wrong. |
| 18 |
|
| 19 |
Centralised effort like that is only of benefit IME if it doesn't contribute to a bottleneck |
| 20 |
or impede the workflow. |
| 21 |
|
| 22 |
Though I admit a carefully constructed subset of repomans checks could be fast enough. |
| 23 |
|
| 24 |
eg: If at all possible, I'd want those tests we need done to be executable without needing |
| 25 |
to source the ebuild or any of the profiles. |
| 26 |
|
| 27 |
Things like MANIFEST checking and metadata.xml validation can probably be done without this |
| 28 |
as long as people do it right. |
| 29 |
|
| 30 |
|
| 31 |
/dev-perl/Dist-Zilla $ time repoman manifest-check |
| 32 |
real 0m1.120s |
| 33 |
user 0m1.020s |
| 34 |
sys 0m0.100s |
| 35 |
cpu 99.98% |
| 36 |
|
| 37 |
But actual checking is really bad with a cold cache ( and I seem to always have a cold cache because |
| 38 |
web browsers are made of bloat ) |
| 39 |
|
| 40 |
/dev-perl/Dist-Zilla $ time repoman full --include-arches amd64 |
| 41 |
|
| 42 |
real 0m51.698s |
| 43 |
user 0m8.890s |
| 44 |
sys 0m7.898s |
| 45 |
cpu 32.47% |
| 46 |
|
| 47 |
Warm cache: |
| 48 |
|
| 49 |
real 0m5.087s |
| 50 |
user 0m4.413s |
| 51 |
sys 0m1.815s |
| 52 |
cpu 122.42% |
| 53 |
|
| 54 |
Warm cache + multiple arches: |
| 55 |
|
| 56 |
real 0m7.469s |
| 57 |
user 0m6.566s |
| 58 |
sys 0m1.893s |
| 59 |
cpu 113.24% |
| 60 |
|
| 61 |
|
| 62 |
I guess it can't be slower than CVS .... but ideally, you want the git commit window |
| 63 |
to be as fast as possible to minimise the chance of contention. |
Archives