1 |
On Thu, 9 Jul 2009 22:16:34 +0200 |
2 |
Christian Faulhammer <fauli@g.o> wrote: |
3 |
|
4 |
> Hi, |
5 |
> |
6 |
> Harley Peters <harley@×××××××××××××.net>: |
7 |
> > Ok that's what I am doing. Was just wondering if there was something |
8 |
> > simple I over looked. |
9 |
> |
10 |
> To give you an idea what we gain here, I compiled some numbers. GNU |
11 |
> Emacs live ebuild (app-editors/emacs-cvs) will be the biggest consumer |
12 |
> once they switch from CVS. |
13 |
> |
14 |
> First we will compare timings |
15 |
> |
16 |
> $ time bzr checkout --lightweight |
17 |
> real 7m37.044s |
18 |
> user 1m2.789s |
19 |
> sys 0m2.807s |
20 |
> |
21 |
> $ time bzr checkout |
22 |
> |
23 |
> real 40m47.371s |
24 |
> user 3m57.881s |
25 |
> sys 0m8.586s |
26 |
> |
27 |
> So the normal initial checkout will be more than five times slower |
28 |
> than the lightweight one. If this were 1s to 6s it would be |
29 |
> neglectable, but we are talking about half an hour difference just |
30 |
> for an emerge. |
31 |
> |
32 |
> Next ist the update function. |
33 |
> |
34 |
> $ time bzr update |
35 |
> |
36 |
> real 0m11.457s |
37 |
> user 0m0.544s |
38 |
> sys 0m0.092s |
39 |
> |
40 |
> $ time bzr update |
41 |
> |
42 |
> real 0m2.710s |
43 |
> user 0m0.237s |
44 |
> sys 0m0.053s |
45 |
> |
46 |
> Clearly the normal checkout wins by factor five, but we are in the |
47 |
> second range, while the space gain is enormous: |
48 |
> |
49 |
> $ du -sch Emacs-lw/ Emacs |
50 |
> 106M Emacs-lw/ |
51 |
> 427M Emacs |
52 |
> 533M total |
53 |
> |
54 |
> V-Li |
55 |
> |
56 |
|
57 |
I understand why you did it. I just need a way to prevent it from |
58 |
deleting a full checkout. |
59 |
Because the numbers don't look so good for Gnash. |
60 |
bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk |
61 |
Having said that it's only a two line change to the bzr.eclass code to |
62 |
get it to work the way I want. |
63 |
And I can live with that. :) |