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ł): [EMAIL PROTECTED] SOURCES]$ ls -l scilab-3.0.src.tar -rw------- 1 undefine users 70778880 2004-07-09 14:37 scilab-3.0.src.tar [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] undefine]$ expr 10761140 - 8540704 2220436 większy, co daje że jest on o: [EMAIL PROTECTED] undefine]$ expr 222043600 / 8540704 25 % większy niż bzip2 no, ale teraz czas rozpakowywania: [EMAIL PROTECTED] SOURCES]$ time gzip -d scilab.tar.gz real 0m3.169s user 0m1.190s sys 0m0.900s [EMAIL PROTECTED] SOURCES]$ rm scilab.tar [EMAIL PROTECTED] 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: [EMAIL PROTECTED] e-mail: [EMAIL PROTECTED] _______________________________________________ pld-devel-pl mailing list [EMAIL PROTECTED] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
