Flipped

With the help of davyd and desrt, I managed to make a release of gucharmap; man..., I thought that module is better-maintained (hi Noah ;)). Anyway, I like the way desrt is making more noise these days. We need warm blood, and I personally appreciate it. We are planning to hit Ubuntu Below Zero together in early November. Anyway, if anybody planning for a release party around T.O., invite me too.

The rest of this post I wrote on September 1st, but was generally too exhausted to polish and post sooner:

So, finally, after ten days of intense hacking, I managed to produce a release:

A new preload release 0.2 is now available from:

http://prdownloads.sourceforge.net/preload/preload-0.2.tar.gz

which can be verified with:

http://prdownloads.sourceforge.net/preload/preload-0.2.tar.gz.sha1
d08fac3ffc0aa2ead473a915d9c422fc76815974 preload-0.2.tar.gz

http://prdownloads.sourceforge.net/preload/preload-0.2.tar.gz.sha1.asc
(signed by Behdad Esfahbod)

An RPM package is available too. You can access all from:

http://preload.sf.net/


preload 0.2 release
===================

This is the first public release of preload. It runs as a daemon and
monitors processes through /proc and predicts applications that may
run and prefetches binaries and shared object. In my experience, it
reduced the startup time of OpenOffice.org writer right after a reboot
from 13 seconds to 7 seconds, and Firefox from 9 to 7. It also decreased
the time from entering login/password information in gdm to a usable
desktop is loaded from 37s to 32s. On the other hand though, the time
from power button is pressed to gdm login screen is functional, was
increased from 65s to 85s, due to excessive harddisk activity caused
by preload.

When I initially wrote the preload proposal, I believed that the idea works, then in the course of the Summer I managed to move my belief to that it works at least at login time, donno whether it does much after that. I'm glad to see after running it that as I initially thought, it works: it simply sees what applications you are interested in and may run. It prefetches all your desktop prior to login too, but that can reduced the GNOME login time only a fraction, say from 37s to 32s. Which makes sense, since GNOME binaries and shared objects are not more than a hundred megs, which is four or five seconds of work loading off the disk. GNOME's startup time problem is known to be caused by gconf, which is what Lorenzo is working on. The combination should be interesting.

The effect on application startup was mixed. For one thing, it reduced the startup time of OpenOffice.org writer by more than 40% (from 13s to 7s), while for Firefox the improvement was a mere 20%. The revealing fact is that the swriter binary has more than 400 maps associated with it, that preload prefetches them all. So, we are talking about something like hundreds of harddisk seek times, which takes some time...

I know people are giving me weird looks about the increase in boot time, but 1) I'm going to fix that, preload is being too aggressive right now, 2) my experiments show that any kind of readahead during boot only makes a tough job tougher and increases the time. This is true for the readahead packages in Fedora Core too.

Update: The 0.2 release had a problem with 64-bit archs, that's fixed in CVS now. Will make a release later this week.

¶ 1:14 AM