| 1 |
On Tuesday 06 April 2004 11:57, Jerry McBride wrote: |
| 2 |
> Nicholas wrote: |
| 3 |
> > Ok, This week's project is to test Gentoo's performance... |
| 4 |
> |
| 5 |
> How about a "performance wish list" ? |
| 6 |
> |
| 7 |
> 1 - Migrate emerge from python to C. |
| 8 |
> 2 - Use a real database for portage instead of a filesystem |
| 9 |
> 3 - .... |
| 10 |
|
| 11 |
4 - Profit???? |
| 12 |
|
| 13 |
But seriously, folks. Number 2 I can see having good points feature-wise, but |
| 14 |
not performance. Same with number 1. |
| 15 |
|
| 16 |
Is the performance gain in changing portage from python to C actually going to |
| 17 |
count for anything? Especially considering we are in the business of |
| 18 |
compiling every package from scratch (hey, we're talking performance here, |
| 19 |
aren't we?). |
| 20 |
|
| 21 |
I'm willing to be that the speed gained by rewriting portage in a compiled |
| 22 |
language such as C/C++ will definitely be lost in the noise of compile time. |
| 23 |
Think about it: |
| 24 |
|
| 25 |
(XP 1800+, 256mb, 2x40gb raid 0 running kde 3.2.1) |
| 26 |
chris root # time emerge bash |
| 27 |
... |
| 28 |
real 2m9.906s |
| 29 |
user 1m10.093s |
| 30 |
sys 0m21.435s |
| 31 |
|
| 32 |
Two minutes 10 seconds. How much of that was spent _NOT_: |
| 33 |
- downloading the package |
| 34 |
- md5sum'ming the distfile |
| 35 |
- configuring the package |
| 36 |
- building the package |
| 37 |
- merging the package to the local filesystem |
| 38 |
- regenerating ld.so.conf |
| 39 |
- Regenerating GNU info directory index |
| 40 |
|
| 41 |
The answer: not a hell of a lot. Maybe 15 seconds MAX. Now with a compiled |
| 42 |
language you could probably cut that down to, say, 5-10 seconds (given that |
| 43 |
IO will limit a lot of these operations). That makes the total build time 2 |
| 44 |
minutes-ish which really, isn't a lot of difference. |
| 45 |
|
| 46 |
Then think further: Python makes a brilliant RAD (rapid application |
| 47 |
development) language with high-level modules for almost any task needed to |
| 48 |
be done, which means the programmers have to program less. |
| 49 |
|
| 50 |
So take that time saved for every build (I imagine it'd be relatively |
| 51 |
constant) for every user and have you made up the time that using python has |
| 52 |
saved the portage developers (I realise that this would be a little hard to |
| 53 |
calculate but I believe a valid point.)? Would we see most of the cool |
| 54 |
features we have in portage today if portage was written in a less intuitive |
| 55 |
language such as C? |
| 56 |
|
| 57 |
This has been discussed time and time again in the forums but I can tell you |
| 58 |
now no rewrite is going to happen. Portage-ng will have a core written in |
| 59 |
prolog (IIRC) and will have bindings out to any other language so that the |
| 60 |
language that best suits the task will be used. So keep an eye on portage-ng |
| 61 |
development, there is a project page on the website. |
| 62 |
|
| 63 |
Cheers, |
| 64 |
Chris. |
| 65 |
|
| 66 |
-- |
| 67 |
gentoo-performance@g.o mailing list |
Archives