I would like to know what are the drawbacks of using preload? If there would be no downside, preload would be enabled by default, so I guess there are some.

Okay you need a bit more RAM, but most people have by far more RAM then Ubuntu needs - so what are the downsides of using preload?

  • 7
    Thank you for your useful question. I want to know, Is it a myth? – Saeed Zarinfam Sep 5 '12 at 5:09
  • 1
    cpu usage and battery might be a drawback for some... bugs.launchpad.net/ubuntu/+source/preload/+bug/481861 – Mateo Sep 7 '12 at 1:12
  • 1
    Nice question. Some distributions do come loaded with preload, such as the elementary OS (which is what I run on my laptop because gala is way faster than Ubuntu's unity). – user69659 Jan 6 '13 at 15:14
  • 1
    Just a guess: One reason for not including it by default is the fact that it is not usable on all systems (its hardware requirements might be different from the standard requirements). – don.joey May 1 '13 at 8:48
  • 2
    brainstorm.ubuntu.com/idea/1122 a post here suggests that it "that it runs as a daemon with root privileges." Which may be a security issue, there is also this brainstorm wanting it's default inclusion brainstorm.ubuntu.com/idea/14092 – Mateo May 4 '13 at 1:17

Simply put, Preload isn't for everyone. It is great if you open applications or libraries a lot. It is harmful if you load applications or libraries only occasionally. I will use two examples from my actual usage (and yes I use preload).

First, Google Chrome. Now a browser is opened only once per boot, maybe twice (for me, I am a web developer). Chrome and its related libraries stay in memory because I am always using it. Even when I close all the chrome windows it's still in the background doing its thing. Thus all the ram dedicated to holding a preload copy of Chrome is a total and utter waste. It's never (or rarely) unloaded. For the average user this is true for a great number of applications. A Office user will almost always have their email app open. So the small savings in startup time is completely wasted because they only open their email app once a day, and leave it open.

The Second example is rake. As a ruby developer that believes in testing I run rake a TON. rake runs, executes for a couple of seconds - minutes then exits. Preload helps me speed up my daily work because it loads rake and its needed libraries (which can be very extensive) ahead of time. So there are a lot of starts and stops to the running of rake. The extra ram used to speed up the 400 or 500 launches of rake over the span of a few hours is totally worth it.

So the reason it's not enabled by default is because its ability to actually improve performance is based largely on how you use your system. For some people it will be a negative and for others a positive.

Lastly, having preload on, even if you're not using it, consumes ram. So if you're not launching applications frequently, you could actually make your entire system fractionally slower by not having that ram available for other types of caching. Remember, even if you have 32 Gigs of ram Linux will try to use as much of it as it can to cache data to make your interaction faster. By using preload you reduce that free memory some. Even if it is just a little tiny bit, the 2 seconds you saved launching chrome 1 time could cost you 60 seconds over the month it stays running.

  • 1
    Also, using preload slows booting up. The more stuff is preloaded, the longer it takes to get your system up and running. Now, imagine that all you want to do is to boot up, write a sentence on a memo, and shut down right after. You'll be waiting to even to be able to write the memo, because your system is preloading things most likely unrelated to that task. Thus, in a way, preloading (in general) is a double-edged sword. – F-3000 Aug 10 '15 at 5:55
  • 2
    Preload isn't actually working that way... It gives the kernel hints like "hey load this into your cache while you are there, I will need it soon" and the kernel does so. So it's actually not using the RAM like you describe it. Two things may happen, tho: Loading into cache pushes out applications that you are going to use soon - which results in a short freeze and hard disk activity when you get back to the application. – hurikhan77 Jan 29 '16 at 20:25
  • 2
    Second: If preload predicts your usage pattern wrong (which may pretty well be the case if your have constantly loaded applications), it caches stuff which will later be pushed out of RAM again and in turn itself pushed cache out of RAM which you may had better use for. But in the end it only "consumes" RAM as the vfs cache does - so it's actually discardable RAM and thus "free RAM" in a way. It does however compete with the "normal cache" as you write. – hurikhan77 Jan 29 '16 at 20:25
  • 1
    Given coteyr and @hurikhan77 recalls above, do you agree Preload is a counter-effective way to help improve perceived speed on older, low RAM (~800 MB free upon startup) desktop boxes. FYI activating Preload on such refurbished boxes will give the kernel virtual memory manager lots of work for little improvment? – tuk0z Sep 13 '16 at 11:33
  • 2
    @lliseil If that 800 MB are really unallocated RAM, preload may help... But it probably works better with more RAM. And in turn that means: Preload will conflict with memory-hungry applications you may start later. Lowering swappiness may be necessary here which then probably renders preload useless as soon as you are going to use too much RAM. – hurikhan77 Sep 13 '16 at 17:53

Question asked by bountier Saeed Zarinfam on September 5, 2012:

Hi all, I want to know, Is it a myth? Does [preload] really improve my performance? What are drawbacks of using it? I have a laptop with this specification (Core i5 CPU, 4GB RAM, 128GB SSD Hard). Thank you so much.

  • There's no real need for preload if you have an SSD
    • This is because SSDs provide much faster random access times than hard disks, so "pre-loading" binaries/dependencies in memory is a waste, IMO
    • The basic downside then is that preload is "using" additional memory without providing a tangible benefit.
  • 24
    This doesn't cover the OP's question as are there any drawbacks to using preload? Second, you have formed an opinion, made a statement about "pre-loading" and then introduced "SSD" into the equation. At what point were you actually going to answer the question? – Ringtail Sep 8 '12 at 21:42
  • 2
    Not to mention it's wrong. I have an SSD, and was looking for ways to speed up atom editor start up, since I use it for everything. Preload cut Atom load time to one quarter of what is was before. Which makes sense - It's always going to be faster to fetch from RAM than it is from SSD, (or indeed anything outside of RAM), because even with SSDs you have to load everything into RAM before it's usable by the processor. It's not usable directly from the disk, SSD or not. – C.Rogers May 27 '20 at 10:17

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 first work experimenting with file-system prefetching at this level as far as we know.

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 effectiveness drastically, especially under tight memory conditions.

Another inherent problem with the preload design is high variance and low prediction confidence 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 infinite 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 file-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.

  • 2
    Thank you for your answer, Mitch. These were my thoughts as well. Especially on laptops preload might be a problem. But still, I would love to find an official source/discussion on why the Ubuntu team decided against shipping preload. – Glutanimate Apr 28 '13 at 9:48

Drawbacks? There are NONE!

Increased performance opening applications by the user. I have used it for years on my systems as well as "read-ahead" and have no issues. The bug page for preload doesn't suggest any drawbacks either.

Preload monitors applications that users run, and by analysing this data, predicts what applications users might run, and fetches those binaries and their dependencies into memory for faster startup times.

It does increase the boot time slightly however the speed decrease fetching time of applications far exceeds this little issue.

see article

If you're constantly using common apps like Firefox or Gimp you'll notice some greatly improved load times. Preload is a daemon that runs discretely in the background and will not disrupt your desktop in anyway. Ubuntu users can install preload with:

sudo apt-get install preload


Graph showing difference between normal and preload start


  • 4
    I know what it dose and I read several 'preload HowTos', but nowhere I could read something about the drawbacks. If there would be no draw backs it would be shipped by default with many Linux distributions - but as far as I know - thats not the case. – Paradiesstaub Mar 5 '12 at 23:20
  • 1
    The performance is not decreased, but increased. That's the whole point of using preload. Maybe it's just a typo. – Marco Sep 5 '12 at 10:10
  • 4
    Your diagram looks great but it lacks important information. It would 100% fit in a powerpoint presentation of a sales guy, but it is an example of 'bad statistics'. Where do these figures come from? What protocol was used to record them? Whas it a single snapshot? How many machines were involved in the sample? What was the hardware? How was the preload program configured? – user85164 May 4 '13 at 22:31
  • 1
    @Ringtail: You're right. You're not the author of that diagram. But if you click through all the links in the articles, you come on a Techthrob.com page that should have hosted an article written by the author of the program. But that page has gone. So there is only source: the thesis of the author. – user85164 May 4 '13 at 23:50
  • 3
    One should upgrade the hardware if a gnome terminal takes more than 2 seconds to start up... – Peter and the wolf Jan 24 '14 at 10:07

Here are some drawbacks of Preload and why it is not that effective for everyone I do have a decent specification system with 8GB RAM. So my system is generally fast. Also, I will open heavy memory-consuming applications, such as Firefox, Chrome, VirtualBox, Gimp etc., one or two times per day. They remain open all the time, hence their binaries and libraries are preloaded into memory and occupying the RAM all day. I rarely close and open those applications, so the RAM usage is simply waste. If you’re using modern systems with SSD, Preload is obviously useless. Because SSDs access time is much faster than normal hard drives, so using Preload is pointless. Preload significantly affects the boot time. Because the more applications are preloaded into RAM, the longer it takes to get your system up and running.

You will only the see the real difference only if you’re reloading applications a LOT of time per day. So Preload will be ideal for the developers and testers who open and close the applications several times every day.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.