Al Hopper wrote: > On Wed, 12 Sep 2007, Roland Mainz wrote: > > Casper.Dik at Sun.COM wrote: > >>> Test case: watch "iostat -xnzc 5" while reading from an > >>> optical media, using different block sizes: > >>> > >>> dd if=/dev/rdsk/c2t1d0p0 of=/dev/null bs=2k > >>> dd if=/dev/rdsk/c2t1d0p0 of=/dev/null bs=32k > >>> > >>> This SONY DVD RW AW-G170A (and a DVD-RW media) > >>> is reading ~3 MB/sec using 2k read requests, and ~8 MB/sec > >>> when using 32k reads. > >> > >> While this matters some, the current install process is so inefficient > >> that even though installing from DVD is slower than the network, a network > >> tends to be idle most of the time during the install. > >> > >> (Which isn't surprising as getting 4GB over local net should not take more > >> than between 40 (Gbps) and 400s (100Mbps) but installs take generally a lot > >> longer than 7 minutes; bunzip2 is also so slow that it cannot stream data > >> from any media faster than papertape. > > > > "bunzip" could be made a bit faster with some simple tricks (like using > > higher optimizer options for the compiler, use largepages for the > > buffers etc.) ... but it would need a sponsor for such a patch > > Optimizing bunzip is not worth the time/effort IMHO.
Why ? It's just flipping a few switches at compiler level... > Because it's a > CPU resource hog and only provides a couple of percentage points > reduction in the compressed file size compared to gzip. By far a > better solution is to ship .gz install files. > > The original decision to ship .bz2 install files was flawed IMHO. Erm, I have to disagree... "bzip2" is in some cases _far_ better than "gzip" - it depends what needs to be compressed... and the extra space saved allows to squish more stuff on the CDs/DVDs ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
