Gentoo Archives: gentoo-dev

From: Christian Faulhammer <fauli@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Problems with the current bzr eclass.
Date: Thu, 09 Jul 2009 20:16:55
Message-Id: 20090709221634.005c6b74@gentoo.org
In Reply to: Re: [gentoo-dev] Re: Problems with the current bzr eclass. by Harley Peters
1 Hi,
2
3 Harley Peters <harley@×××××××××××××.net>:
4 > Ok that's what I am doing. Was just wondering if there was something
5 > simple I over looked.
6
7 To give you an idea what we gain here, I compiled some numbers. GNU
8 Emacs live ebuild (app-editors/emacs-cvs) will be the biggest consumer
9 once they switch from CVS.
10
11 First we will compare timings
12
13 $ time bzr checkout --lightweight
14 real 7m37.044s
15 user 1m2.789s
16 sys 0m2.807s
17
18 $ time bzr checkout
19
20 real 40m47.371s
21 user 3m57.881s
22 sys 0m8.586s
23
24 So the normal initial checkout will be more than five times slower than
25 the lightweight one. If this were 1s to 6s it would be neglectable,
26 but we are talking about half an hour difference just for an emerge.
27
28 Next ist the update function.
29
30 $ time bzr update
31
32 real 0m11.457s
33 user 0m0.544s
34 sys 0m0.092s
35
36 $ time bzr update
37
38 real 0m2.710s
39 user 0m0.237s
40 sys 0m0.053s
41
42 Clearly the normal checkout wins by factor five, but we are in the
43 second range, while the space gain is enormous:
44
45 $ du -sch Emacs-lw/ Emacs
46 106M Emacs-lw/
47 427M Emacs
48 533M total
49
50 V-Li
51
52 --
53 Christian Faulhammer, Gentoo Lisp project
54 <URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
55
56 <URL:http://gentoo.faulhammer.org/>

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Re: Problems with the current bzr eclass. Harley Peters <harley@×××××××××××××.net>