1 |
On Mon, 14 Aug 2017 13:31:53 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> On 08/14/2017 12:49 PM, M. J. Everitt wrote: |
5 |
> > On 14/08/17 08:39, Zac Medico wrote: |
6 |
> >> From: Hidehiko Abe <hidehiko@××××××××.org> |
7 |
> >> |
8 |
> >> doins is written in bash. However, specifically in case that |
9 |
> >> too many files are installed, it is very slow. |
10 |
> >> This CL rewrites the script in python for performance. |
11 |
> >> |
12 |
> >> BUG=chromium:712659 |
13 |
> >> TEST=time (./setup_board --forace && \ |
14 |
> >> ./build_package --withdev && \ |
15 |
> >> ./build_image --noenable_rootfs_verification test) |
16 |
> >> ===Before=== |
17 |
> >> real 21m35.445s |
18 |
> >> user 93m40.588s |
19 |
> >> sys 21m31.224s |
20 |
> >> |
21 |
> >> ===After=== |
22 |
> >> real 17m30.106s |
23 |
> >> user 94m1.812s |
24 |
> >> sys 20m13.468s |
25 |
> >> |
26 |
> > I know I'm gonna get chewed out on this one, but here goes |
27 |
> > anyway ... |
28 |
> > |
29 |
> > Surely for a package like chromium, who's build time is already in |
30 |
> > the 'hours' range anyway, surely a couple of minutes gain for the |
31 |
> > install phase is neither here nor there?! If there were some |
32 |
> > genuine filesystem iop gains/etc for this change, I think I'd |
33 |
> > likely support it further .. |
34 |
> |
35 |
> It's going to reduce time, power consumption, and heat generation for |
36 |
> all portage users. Also, we can use portage.util.file_copy to optimize |
37 |
> it further with zero-copy, reflink, and sparse file support. |
38 |
> |
39 |
> > On this basis, what do the performance differences look like on an |
40 |
> > 'average' package |
41 |
> |
42 |
> Well, it's very inefficient to fork/exec the install command for many |
43 |
> files as the existing bash implementation does. The performance |
44 |
> difference is related to the number of files. |
45 |
> |
46 |
> > .. and are there any regressions in this regard?! |
47 |
> |
48 |
> It's supposed to fallback to calling the install command if there are |
49 |
> any unrecognized options, so the intention is for 100% compatibility. |
50 |
> |
51 |
> > I take issue with the copyright assignment, as I believe the |
52 |
> > legal .. err .. IANAL devs are campaigning for full rights to be |
53 |
> > owned and enforced by Gentoo Inc LLC in the US .. even if they have |
54 |
> > no idea what that means or does .. :] |
55 |
> |
56 |
> Since it's a BSD-style license, we can copy the code into our project |
57 |
> as long as we retain the copyright notice. |
58 |
|
59 |
Patches look fine to me, glad for the speedup :) |
60 |
|
61 |
-- |
62 |
Brian Dolbec <dolsen> |