Ktoś mi to może wytłumaczy...

[The Undefined]

On Sat, Jul 31, 2004 at 12:54:31PM +0200, Tomasz Pala wrote:
> > > > > ~10% smaller vs. 5 -7 times slower
> > > > czy to źle?
> > > 
> > > Tak.
> > nie ;)
> 
> Ależ owszem:P
bynajmniej! ;)

> > > Właśnie sobie kilka razy java-blackdown spakietowałem...
> > i często pakietujesz java-blackdown na "produkcyjnych" maszynach? 
> 
> Ja nie. Ale buildery PLD są maszynami produkcyjnymi i robią to chyba
> dość często.
ee.. przesada.
w większości pakietów _subiektywnie_ najwięcej czasu zajmują kompilacje,
rozpakowywanie źródeł itepe. A czas pakowania tego do rpm-a jest raczej
pomijalny.
javy są tutaj raczej wyjątkiem(bo w sumie to je się wyłącznie
przepakowuje), na dodatek złym bo jak na razie to javy w pld nie ma ;)

> > Dla builderów z koleji nawet kilka minut róznicy przy jakiejś dużej
> > paczce nie zrobi wiekszego kłopotu.
> 
> ZTCW to są buildery szybsze i wolniejsze. Może na tych wolniejszych
> włączyć gzip -1? Te pakiety raczej nie są wykorzystywane powszechnie,
> więc mogliby się wypowiedzieć ci, którzy ich używają.
w momencie gdy nie są wykorzystywane powszechnie tym bardziej imho
należy je kompresować - "strata" użytkowników będzie tym mniejsza, a
zysk na ftp spory (tutaj też trzeba patrzeć - w tej chwili athlon
zajmuje jakieś 4GB, 10% z tego to 400MB - niby niezbyt dużo, ale zawsze
coś...
Co do builderów - w tej chwili chyba tylko ppc dosyć znacznie odstaje od
normy. Ale przy normalnej kompilacji i tak kilkanaście sekund więcej nie
robi zbytniej różnicy gdy pakiet się kompiluje kilka minut.
a przy rozpakowywaniu między gzip a bzip2 już takiej ogromnej różnicy
nie ma.
ot(największy tar.gz jaki miałem u siebie, po rozpakowaniu ponad 70MB źródeł):
[undefine w sv1 SOURCES]$ ls -l scilab-3.0.src.tar 
-rw-------  1 undefine users 70778880 2004-07-09 14:37 scilab-3.0.src.tar

[undefine w sv1 SOURCES]$ cat scilab-3.0.src.tar |time gzip -9 >scilab.tar.gz
15.43user 9.20system 0:29.06elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (86major+86minor)pagefaults 0swaps
[undefine w sv1 SOURCES]$ cat scilab-3.0.src.tar |time bzip2 -9 >scilab.tar.bz2
59.06user 38.36system 2:12.20elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (108major+1850minor)pagefaults 0swaps

czyli jak widać czas pakowania 4-krotnie dłuższy. Za to:
[undefine w sv1 SOURCES]$ ls -l scilab.tar.*
-rw-------  1 undefine users  8540704 2004-07-31 14:02 scilab.tar.bz2
-rw-------  1 undefine users 10761140 2004-07-31 14:00 scilab.tar.gz

czyli gzip jest o:
[undefine w sv1 undefine]$ expr 10761140 - 8540704
2220436
większy, co daje że jest on o:
[undefine w sv1 undefine]$ expr 222043600 / 8540704
25
% większy niż bzip2

no, ale teraz czas rozpakowywania:
[undefine w sv1 SOURCES]$ time gzip -d scilab.tar.gz
real    0m3.169s
user    0m1.190s
sys     0m0.900s
[undefine w sv1 SOURCES]$ rm scilab.tar
[undefine w sv1 SOURCES]$ time bzip2 -d scilab.tar.bz2
real    0m21.176s
user    0m10.640s
sys     0m7.510s

no.. rzeczywiście jest 10 krotnie dłuższy czas rozpakowania. z tym że
dla 70MB pliku... kilkanaście sekund różnicy chyba nie gra wielkiej
roli?

maszynka testowa - athlon 2000+, co nieco obciążony w tej chwili, ale to
akurat nie powinno mieć wielkiego znaczenia ;)

> > > Często. A przy wysokim load czekanie jest dobijające. Nie wspominając o
> > > zużywanej pamięci, która może łatwo doprowadzić do swapowania.
> > to po co wogóle z poldka korzystać? przy użyciu przez poldka kilkunastu
> > MB ram, dodatkowy megabajt na bzip2 nie robi dużej różnicy.
> 
> A wiesz, że czasem opiekuję się maszyną z 16MB RAM na Ac?
i używasz na niej poldka? :)
szczerze współczuję...
ja już na maszynkach z 48MB ram (a kilka takich mam) się czasami
wściekam na zużycie pamięci...

> > > > praktycznie pominąć czas tego... który i tak zwykle nie przekracza
> > > > kilku/nastu sekund. A wielkość... przy łączu rzędu 256kbit ściągniecie
> > > > 10MB a 11MB to jednak różnica...
> > > 
> > > Pół minuty...
> > a przy załozeniu że to łacze jest już w 90% wysycone? ;)
> 
> Zaraz zaraz... 256kbit per user się daje, nie? :P
haha :)
jak user zapłaci to się daje. niestety u mnie częściej jest 2mbity na
blisko 100 userów ;)

> > ja w domu, w szczycie często miewam transfery rzędu 8-10kB/s. A przecież
> > są ludzie mający jeszcze gorsze łącza...
> 
> Fatalnie... jaką politykę wobec p2p stosujesz? Bo jak mi transfery w
> szczycie spadły do 10kB/s (w podziękowaniu za 22% VAT zrezygnowaliśmy z
> 1Mb/s), to zepchnąłem je do osobnej klasy (wcześniej miałem podział
> tylko po IP).
aktualnie podział przez ip. nie znalazłem skutecznego sposobu by
kolejkować p2p - za dużo było takich którym p2p na porcie 80 łaziło...
Pozatym formalnie to nie moja broszka z czego kto korzysta. Ja sie tylko
martwię by transfer nie spadł poniżej odpowiedniego minimum... a
nałogowych ssaczy troszke mocniej przycinam...

-- 
Andrzej 'The Undefined' Dopierała
UNIX && Linux administrator, Adam Mickiewicz University WMiI
PLD Linux Developer             HomePage: http://aramin.net/
JID: undefine w piastlan.net    e-mail: undefine w pld-linux.org