I’ve used prelink in the past on Ubuntu in an attempt to speed up application loading, but I’ve never actually done any benchmarks to test the results. I decided today to run some simple benchmarks to gauge the performance increase of using prelink.
For readers too lazy to read through the entire article, I will summarize by saying that using prelink does reduce application load time.
Read about prelink and what it does on Wikipedia. Explaining it is beyond the scope of this article.
Testing methodology:
Programs that will be used for testing:
Testbed:
First, the results without prelink:
| Test | 1st | 2nd | 3rd | Avg |
| OpenOffice.org | 7.65 | 7.06 | 7.24 | 7.32 |
| Firefox 3 | 6.45 | 5.31 | 5.12 | 5.63 |
| Azureus | 11.67 | 11.14 | 11.31 | 11.37 |
| Tremulous | 3.56 | 3.28 | 3.52 | 3.45 |
| Evolution | 5.42 | 5.36 | 5.47 | 5.42 |
| Gimp | 5.93 | 6.01 | 5.88 | 5.94 |
Now, I will install prelink, take the system down to single user mode, run the intial prelink session, and reboot:
# sudo aptitude update && sudo aptitude install prelink
# sudo init 1
# sudo /etc/cron.daily/prelink
# sudo reboot
Now that prelink has run, it’s time to run the benchmarks again and check the results!
| Test | 1st | 2nd | 3rd | Avg |
| OpenOffice.org | 6.62 | 6.61 | 6.83 | 6.69 |
| Firefox 3 | 5.40 | 5.92 | 5.07 | 5.46 |
| Azureus | 11.10 | 11.25 | 11.16 | 11.17 |
| Tremulous | 3.30 | 3.12 | 3.48 | 3.30 |
| Evolution | 5.39 | 5.45 | 5.32 | 5.39 |
| GIMP | 5.72 | 5.93 | 5.68 | 5.78 |
These benchmarks clearly show that prelink generates a measurable performance improvement in application load time. Considering that the time needed to install and configure prelink is minimal, and the gains are obviously very real, it logically follows that using prelink is A Good Idea.
0.63 seconds may not seem like very much time saved, but consider if you launched OpenOffice five times a day. That’s 3.15 seconds a day. Six days a week that comes to 18.9 seconds a week. That’s 982.8 seconds a year. 9828 seconds over ten years. Etc, etc. It adds up.
I’m saving lives here! Somebody pin a medal on me.
I don’t agree with the conclusion. A difference of less than a second in start up time, is measurable, but not noticeable in practice by a human. Add to that that prelink uses CPU time and causes extra I/O while it is prelinking (which happens when you are working on your computer via anacron for most poeple who don’t let their computer powered on at night!), so actually it will slow down your computer at that moment. If you added this in the calculation, in the end the netto effect would have been less than zero…
Prelink was good at the time Glibc and Binutils did not have hash-style=gnu, but nowadays when using hash-style=gnu, binutils does have very little effect, as is shown by your measurements.
It may or may not be noticeable by a human. That isn’t the point though, the point is that it does save time.
After the initial prelink, subsequent runs are much faster, except for when the libraries are updated. I think the benefits outweigh the drawbacks though.
Agree with you regarding hash-style=gnu.
It saves (a very minimal amount of) time starting up apps, but it costs CPU and more importantly I/O time prelinking apps which happens while you use your computer, so it slows down running applications at that moment (especially on laptops with slower hard drives). If you add this to the calculation, the netto effect will certainly be negative. It’s more a psychological solution for people who think their computer will become faster with a small software hack. But of course you are free to believe it
Whether or not prelinking happens when you are using your computer depends on the individual use case. In my case it does not, since my computer is always on.
I do not believe the net result is zero or less than zero. If you do, please find a scientific way to make your case.
I’m probably going to do more extensive tests with more varied hardware to compare the results. I hypothesize that the results on older computers will be more substantial.
I thik with time Prelink will speed up overall, once it ‘learns your habits’ of what you use and do not use often. I could be wrong but that is my understanding of it. I use it.
This is not true. Prelink is a one time thing, once it’s done, it’s done.
I think you are thinking of preload, which is a readahead daemon that loads frequently used programs and files into RAM. Benchmarks for it will come soon if I have a good response.
What do you think about preload?? How different is it as compared to prelink??
I’ve used preload before, but not benchmarked it.
Preload runs as a daemon and records usage statistics about different files, then loads frequently accessed files into “free” or “cached” RAM, thereby reducing application startup time.
I may post some benchmarks using preload in the future. Since I have a relatively large amount of RAM, I should expect it to improve performance.
Nice and very useness for us the linux users
prelink mess up with OSSEC or any other integrity checking tools.
The benefits are so minuscule that it’s really not worth it.
It saved average Joe Schmo 18 seconds in a week, multiply it by 1000 users for a an average enterprise - 5 hours! Wow! Huge increase in productivity! It’s 50% of what was achieved last year by oiling the door hinges in the bathrooms!!
Now subtract time spent by security IT guy trying to figure out why md5 checksum on /bin/login changed on 1000 systems, cost of disk space on corporate email system where all alerts went, time spent by IT manager reading the analysis on the incident report for false alert. And that is only if those alerts didn’t trigger pager escalation and manager didn’t call for 2 hour meeting with 15 people to resolve “rootkit issue”.
And in general, it’s bad, very bad idea. It’s like crutches for person with broken leg - sure it helps, but may be you should not use that person as mail courier.