Preload is an “adaptive readahead daemon” that runs in the background
of your system, and observes what programs you use most often, caching
them in order to speed up application load time. By using Preload, you
can put unused RAM to good work, and improve the overall performance
of your desktop system.
Don’t expect to see a drastic change in performance
right away. Also, if you’re just opening/closing applications
repetitively, your computer will store those files in cache anyway
(this is called a “warm” load), so you won’t see any difference in
speed there. You will, however, see a speed improvement if, for
example, you use a program intermittently; these programs will start up
faster than without Preload.
Preload can provide a great improvement in application start up time;
since most modern machines have a good deal of memory to spare,
Preload puts this RAM to good use.1
Now that being said, it seems that preload is a great utility, and it might be.
I think that the reason its not preloaded with the OS, is because the user has to know exactly what there doing, and have enough experience to be able to use it, and the system has to have enough RAM.
On a more technical aspect, preload works by moving data from the hard disk to RAM, which makes most hard disk to go to sleep mode if not used, and then have to spin back up when needed. So spinning up/down the drive, would cause the Load/Unload Cycle count, and the Power-On time count rise, and that will shorten the life of the drive.
We designed and implemented preload, a Markov-based adaptive
prefetching scheme that works on application-level predictions.
Moreover, preload is implemented in the userspace and does not change
the application run-time environment in any sense. This is the ﬁrst
work experimenting with ﬁle-system prefetching at this level as far as
Our experimental results show promising improvements on application
start-up time compared to cold caches, and a decent hit rate compared
to a na¨ıve prediction algorithm.
However, being in user-space introduces major obstacles into making
preload a competitive solution to the startup-time problem. In
particular, not having full information about applications’ I/O
requests, and lack of strong communication channels with the
page-cache subsystem degrades preload’s eﬀectiveness drastically,
especially under tight memory conditions.
Another inherent problem with the preload design is high variance and
low prediction conﬁdence caused by the relatively loose correlation of
application start-ups. While we successfully build a model to track
application correlations, the fact that application launches are very
rare events compared to the timescale that computers work on, an
application-level prefetching scheme is condemned to consume huge
prefetching memory over practically inﬁnite periods of time. This
memory can be used to improve short-term cache behavior.
Finally, we come up with a set of recommendations for system
developers on how to improve boot-time, login-time, and application
startup-time without falling back to a prefetcher integrated with the
cache subsystem in the kernel. Of course, a ﬁle-based prefetcher in
the kernel can improve on top of that.2
2Source:Preload - An Adaptive Prefetching Daemon by Behdad Esfahbod - A thesis submitted in conformity with the requirements for the degree of Master of Science - Graduate Department of Computer Science - University of Toronto Copyright (c) 2006 by Behdad Esfahbod.