TIP: Improve bootup speed by reprofiling bootup

[jdong]

After I mentioned the results of this test to Scott James Remnant, Edgy's readahead program was changed in two ways:

(1) It's now done in the foreground
(2) On each bootup, the list is dynamically resorted to match on-disk layout


So, this should mean that Edgy will boot faster without the need for reprofiling, unless of course you start a lot of services that are not part of the default Edgy system.

[Rob2687]

On my P3 laptop, profiling took it from 65s to 56s. Removing the --background thing didn't make a difference.

[mjpatey]

Nice, thanks! The first hack shaved 3-4 seconds off my boot time, and the second one didn't apply, as --background had already been removed.

But good to know I'm now at maximum boot efficiency!

[jdong]

I have authorized for Edgy's readahead-list to be backported to Dapper. This makes foreground the default mode of readahead, and also resorts the list on-the-fly on each bootup.

Enjoy!

[raphha]

Hi jdong,
first, thanks and nice idea. this seems to improve bootup time for me, too (didn't take any measurements yet).
Just one thing I don't understand: why should I want to resort the list every time I boot? Normally, the standard boot files don't really change their places and resorting will surely cost some time - surely I'm missing something?

cheers, raph

[jdong]

Hi jdong,
first, thanks and nice idea. this seems to improve bootup time for me, too (didn't take any measurements yet).
Just one thing I don't understand: why should I want to resort the list every time I boot? Normally, the standard boot files don't really change their places and resorting will surely cost some time - surely I'm missing something?

cheers, raph

(1) Resorting the boot list takes about 50 milliseconds to do on my Celeron M 1.4GHz. If you notice this, then you need to step away from the caffeine pills

(2) The resort-on-boot is primarily designed so that the default, unprofiled boot.list that ships with readahead-list would be more valid on more systems. They are generated on fresh-installed Ubuntu's using ubiquity, which might be vastly different than what your box may be.

(3) Resort-on-boot can help you out when system packages get dist-upgraded. When files are replaced, there's no guarantee that they remain in the same locations. Even security updates might replace some of these bootup files.

[Velox Letum]

Had already profiled myself, but removing --background had a significant impact. Nice tip!

[jdong]

For "power users" who can do a bit of tinkering, you can build your own readahead lists. Run "sudo readahead-watch -o /etc/readahead/myapp.list" to start readahead monitoring and write a list to /etc/readahead/myapp.list. Run "sudo killall readahead-watch" to stop monitoring after you're done.

Then, run " (sudo) readahead-list /etc/readahead/myapp.list" to prefetch myapp.list. Running without sudo just means the app won't resort before reading.

So, you can tinker with readaheading various lengthy tasks. I've had good success with readaheading GNOME/KDE startup (hint: have /etc/rc.local prefetch your list, so if you don't immediately login, readahead will prefetch your login sequence anyway) and openoffice (just created a /usr/local/bin wrapper script). With firefox, there was no improvement, presumably not enough disk IO to make a real impact.

[domino]

Thanks for the how-to. What puzzles me in the Bonus hack is that "--background" was already removed even before i knew the file even existed on my box.

A picture is worth a thousand words. I didn't notice any performance gained by this how-to. Is it possible that anyone can glance at the boot chart and see where it's taking it's time?

Boot time before profile:



Boot time after profile:



Thanks

[jdong]

As I noted in post 36, dapper-backports now uses foreground as its default mode of operation.