1 |
On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen <grobian@g.o> wrote: |
2 |
> On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote: |
3 |
>> [...] Besides, sorting even 30,000 |
4 |
>> entries (if you're merging every ebuild in portage) should not take |
5 |
>> more than a few secs. |
6 |
> |
7 |
> A linux kernel has around that much of files, and I really wonder if |
8 |
> it's worth waiting a couple of seconds (probably more on sparc and arm |
9 |
> systems) just because then the files are in sorted order. |
10 |
> |
11 |
|
12 |
I'm not sure the two are really comparable. However, looking at a |
13 |
simple string sort on 30,000 strings, I don't see it taking a |
14 |
significant amount of time at all: |
15 |
|
16 |
import random |
17 |
import time |
18 |
t1 = time.time() |
19 |
a = range(100000, 130000) |
20 |
random.shuffle(a) |
21 |
b = [str(i) for i in a] |
22 |
t2 = time.time() |
23 |
b.sort() |
24 |
t3 = time.time() |
25 |
print(t2-t1) |
26 |
print(t3-t2) |
27 |
|
28 |
---- |
29 |
0.0682320594788 |
30 |
0.0464689731598 |
31 |
|
32 |
|
33 |
>> 1. I'm obviously assuming that dep nodes that do not depend on each |
34 |
>> other would be sorted |
35 |
> |
36 |
> I think this is per package. |
37 |
> |
38 |
|
39 |
Actually, reading the code it seems that it's about the file merge |
40 |
order of a single package. My participation in this entire discussion |
41 |
is m00t. Never mind. :p |
42 |
|
43 |
-- |
44 |
~Nirbheek Chauhan |
45 |
|
46 |
Gentoo GNOME+Mozilla Team |