‘Effects’ of Using ‘preload’ (‘readahead daemon’) in Ubuntu 13.04

When a user runs a program, the operating system first loads its data into ‘RAM’ (Random Access Memory -- a very fast data storage medium used in computers that can hold data temporarily). And when that program gets terminated, the operating system, rather than completely getting rid of its data on RAM, moves the program and its data into another location on RAM called the ‘page cache’.

If the user reruns the program (say after a short while), then the OS first looks for its data in the ‘page cache’, and if the data is there (fully or partially), then the program will be loaded very fast compared to the first time, because the operating system doesn’t have to read its data from the main storage device which is few times slower than RAM.

So in other words, by intelligently managing the ‘page cache’, the operating system can significantly improve the application loading times and enhance the user experience, dramatically. And one way of optimizing the ‘page cache’, is to use a technique called ‘data prefetching‘. Data prefetching is the process of loading applications & their other data (such as shared libraries) into the ‘page cache’, even before the user accesses (opens) them. The only way the operating system can do this is by keeping a track of the most frequently used programs by a user, and then based on the history of their used frequency, it has to guess which of these data the user might request in the near future, and then it has to copy them over to the page cache on RAM, beforehand. In GNU/Linux, data ‘prefetching’ is called ‘readahead’.

The ‘page cache’ is managed by the operating system’s Kernel, and most operating systems (including GNU/Linux), don’t use ‘aggressive’ data prefectching techniques when managing the ‘page cache’. But if you’re a GNU/Linux user, then you can use tools like ‘preload’ for enabling aggressive data ‘prefetching’ or to improve its efficiency, in other words.

What is ‘preload’ ?

‘preload’ is a tool that monitors & keeps a history of the user’s most frequently used applications (& the files that those applications load upon their execution). And based that data, it then tries to guess what app the user will be most likely to open in the near future & then loads that data from the disk drive to the ‘page cache’, before they’re requested. In plain simple terms -- once ‘preload’ is installed, after a while you should be able to open your frequently used applications much faster.

‘preload’ is not a new tool but somehow, I never really didn’t test it out. However, this time I decided to try it on on a newly installed Ubuntu 13.04, and ran few tests to see how good it performs. But before running any of these tests, I booted into the newly installed Ubuntu 13.04 a couple of times to let things settle down (some newly installed services and applications require a couple of reboots for properly configuring their setting). It was only after that I ran my tests.

This is what I did.

Before installing ‘preload’, I measured the boot-up times of Ubuntu 13.04 and the loading times of 4 applications -- Firefox, GIMP, LibreOffice Writer & Ubuntu Software Center (USC).

So the first time, once the OS booted, I took a note of its boot-up times, let the OS idle for about 30 -- 40 seconds. Then I opened Firefox & measured its start-up times (I had configured it to open a blank page, so it didn’t really load any webpages) and closed it. Then I opened GIMP, measured its start-up times and closed it. I did the same to LibreOffice Writer and USC.

Once done finished measuring everything, I rebooted the PC & ran the same tests all over again. I followed this ‘cycle’, approximately 5 times, for getting conservative results.

Testing with ‘preload’ installed…

Then I installed ‘preload’, but before running the same tests, I did the following.

As mentioned earlier, for speeding up the app start-up times, ‘preload’ first needs to build a ‘database’ (a ‘probability model’ to be precise). It monitors the run-time of an application (ignores anything that runs below 20 seconds) & the memory usage, for calculating the importance of an application.

So after installing ‘preload’, I opened Firefox, GIMP, LibreOffice Writer & USC. And I kept them all opened for about 3 minutes. In the mean time, I also switched between each app here & there, and also typed some text into Writer, opened a web page on Firefox etc. In other words, I tried to emulate a ‘normal’ user session.

Once finished, I rebooted the PC & reran the emulation process, all over again. This was carried out 5 times, assuming that at the end, ‘preload’ should have created a decent database for prefetching files.

After I was satisfied with the results I started to measure the boot-up times & the app loading times, just like before. Here too I took 5 samples. So using the gathered data, I came up with the below graphs.

Boot-up Times

As you can see, the boot-up times with ‘preload’ installed was slightly slower than without it because ‘preload’ starts while the computer is booting (in ‘user-space’ -- with user privileges) and starts prefetching data into the ‘page cache’. Still, its (negative) effect is minimal.

You’ll also notice that, if you had read my Ubuntu 13.04 review, the boot-up times without ‘preload’ here & the boot-up times that I mentioned in that post, are also slightly different. That is pretty normal in Ubuntu mainly due to ‘ureadahead’ I suppose (ureadahead is also a data prefetching system service but it’s especially designed to improve boot-up times) as the boot-up times varies a bit. And it is for this very reason that I decided to remeasure the boot-up times, rather than using the data from the review.

Furthermore, in this occasion, I also ran ‘apt-get’ to install GIMP, and added its icon to the application launcher, and sometimes doing things like these can slightly affects the boot-up times. So that’s why I took extra steps to make sure the data I gathered remain as accurate as possible.

App loading times (without & with ‘preload’)

As you can see, start-up times of Firefox, GIMP & LibreOffice Writer have been reduced by 44.4%, 16% & 60.7%, respectively, after installing preload. Firefox & Writer are the heavily affected ones (probably because I was ‘working’ with them a lot while ‘training’ preload — just a guess a though).

Below is the graph for Ubuntu Software Center.

As you can see, I don’t know why, but with ‘preload’, the loading times have actually increased (14%). I tested it more than 5 times, just to make sure, but it was pretty much the same.

Another thing that’s worth mentioning is that, after ‘preload’ was installed, when I logged into the desktop, on most occasions the Wi-Fi adapter was already connected to my wireless router. Without ‘preload’, even after fully loading the desktop, it usually take another few more seconds for connecting. This is not a surprise because even though the user won’t be using it directly other than the first time you setup the network, it is still a user application. And as far as ‘preload’ is concerned, it is also a frequently used application by the user (which it is, you just don’t directly use it mostly, that’s all).

Memory usage

‘preload’ runs as a daemon and under most conditions, it never used more than 2.5-3.1 MiB. But since it does its ‘real’ work inside the ‘page cache’, what’s worth measuring is the ‘page cache’ usage (size), not the memory used by the ‘preload’ daemon.

It is also worth noting that, almost all the operating systems use all the available ‘free space’ on RAM for the ‘page cache’. And, although the ‘page cache’ plays a major role concerning performance, responsiveness & stability, the OS does not hesitate to purge some or all of its content, if an application requests some space on RAM for its execution.

So perhaps it’s because of this subtle ‘negligence’ that almost all operating systems when showing memory usage, especially the system monitor GUIs, disregard the ‘page cache’ size & consider it to be ‘free space‘

But in GNU/Linux, one can monitor the ‘page cache’ usage by using the cat /proc/meminfo command and then having a look at the value under ‘Cached’, as shown below.

Below is the initial ‘page cache’ size that I measured upon loading the desktop, without & with ‘preload’:

As you can see, after ‘preload’ created its database and was fully operational, the initial ‘page cache’ size got increased around 70%. This is no surprise. And depending on the complexity of its database, it will occupy more or less space inside the page cache as well.

---

Now wait a minute!. How come, that after adding another extra 250MB+ data (in this instance) into RAM, the boot-up speed is not affected by that much ?

The answer is simple actually. ‘preload’ populates the ‘page cache’ in two steps. It first loads few of the data during the boot-up process, and loads rest of the data (which is much bigger in size) after the desktop is fully loaded. It is for this reason, the boot-up times was not negatively affected by that much.

---

Users don’t actually have to worry much about the ‘page cache’ size increase, as the OS will get rid its data, depending on the need of the running applications. That said, a busy ‘page cache’ consumes the bandwidth of your RAM & can make the disk drive busy (if it ends up reading lots of data frequently), and if not carefully managed, can slow down the operating system.

While ‘preload’ lets you tweak its settings through a centralized configuration file (/etc/preload.conf), unless you know what you’re doing, I it’s better to leave the settings to their default values.

Responsiveness & stability

As mentioned above, ‘preload’ works by prefetching files from the disk to the ‘page cache’, which may increase disk reads, more than usual. So in a situation like heavy multitasking, would it decrease the stability & responsiveness ?

Well, the best way of knowing is to try it yourself. And as usual, I performed a simple stability test. I copied a file about 1.3 GB & while it was being copied, I opened ‘Dash’ & did a few searches, opened the ‘System Settings’ window, opened ‘Writer’, USC, GIMP, Firefox et to see what would happen.

So how did it go ?

Well, to be honest, I couldn’t see a change in the responsiveness. It was, in my experience, pretty much the same.

Also note that, according to its developers, ‘preload’ has the ability to ‘detect’ when the system is idling & will literally halt prefectching, so the disk drive’s power saving features (‘spin down’ for example) aren’t negatively affected.

Final words …

If you’re looking for a way to speed up the application loading times without sacrificing much, then yes, ‘preload’ is a utility that is well worth trying (feel free to throw in your opinion using the comments section). You can install it on Ubuntu 15.10, 15.04, 13.04, 12.10, 12.04 … by using the below command.

sudo apt-get install preload

Once installed, reboot the computer & use it as usual. When ‘preload’ has gathered enough data, you should see an improvement of your application loading times. Good luck.

Note: The ‘page cache’ analogy that I included here is only a basic one. But it should still help most users to get a basic idea nevertheless.