Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Name:
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Google
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
Archives
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Wednesday, September 07, 2005
 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.

Comments: Post a Comment

Links to this post:

Create a Link



<< Archive
<< Home