install smallest legal .rpm first

[John Reiser]

On 02/20/2011 11:43 PM, FlorianFesti wrote:
> On 02/20/2011 11:42 PM, John Reiser wrote:
>> I want to use "smallest .rpm first" from all the compatible choices
>> because it will be faster on my systems.  How can I do so?

> You don't want to try that. Implementing this will take you much more time than you are going to save. Actually I wonder how this can save any time at all.

I will save a couple percent because the harddrive directory operations
for new files will tend to be "as busy as possible", and thus as efficient
as possible, during the early part of an install/upgrade of many .rpms,
instead of being random, and thus less efficient, over the entire duration.

I will save several percent because the source of _my_ .rpms often is
a DVD with the files arranged on the platter in increasing order
of size.  ISO-9660 requires that a directory be sorted alphabetically
by filename, and by default mkisofs puts the files on the platter
in that order.  But the directory pointers to extents, and the -sort
option of mkisofs, enable other organizations.  Placing and processing
by size also maximizes the chance that the 2MB buffer RAM in the DVD
drive can be an effective read-ahead cache from one .rpm to the next.
Even if not, seeks will be shorter and faster.

Finally, I will save a couple tens of percent because I am pipelining
the operations: overlap fetch+decompress of the next .rpm with cpio+%post
of the current .rpm.  The speed of gzip decompression might be within
an order of magnitude of the speed of the harddrive, but decompression
by lzma or xz is slower.  Also, today many machines have 2 or more CPUs.
Ordering the .rpms by size tends to minimize slack time in the pipeline
because the amount of work in simultaneous stages tends to be as equal
as possible.  Pipelining also helps to reduce overall time by overlapping
computation with DVD seeks (and spin-up operations after .rpms that
take "too long".)

--