Uniblue Registry Booster 2010 Review

Performance tests

---

As we mentioned at the start of the review, unless you have a very effective ad-blocker, you’re bound to run into the ads about Registry Booster every now and again. Besides repairing registry errors, one of the product claims is improving system performance, as highlighted in the following ad we spotted a short while ago:

So on this page, we will run Registry Booster on 4 computers and compare before and after results. As Registry Booster’s repair and defragmentation operations can be carried out independent of each other, we will take a look at the performance before installing Registry booster, after repairing the registry and once more after running the registry defragmentation process.

Preparing for the tests

---

The most intensive registry operations occur while booting the PC and while launching applications. When booting the PC, Windows needs to load the registry into RAM and process its entries for loading drivers, start-up processes, GUI customisations, locate Fonts and so on. When launching an application, the registry is used to locate shared DLL files, ActiveX & OLE plug-ins, software settings and so on. When there is a build-up of invalid entries, the boot and application start-up process can take longer than it should due to processing these unnecessary entries.

To avoid applications notifying about updates during our tests, we started by ensuring all our test PC’s antivirus and Windows updates were up to date, the applications used were the latest versions (apart from Word / Publisher) and that any new updates were applied, such as for Flash and Java. Each PC was also left sitting idle for an hour to ensure there were no other update messages.

So for each PC, we picked a handful of applications and added them to the “Quick Launch” bar, such that we could launch each in sequence immediately after the Windows desktop appears. We start timing from immediately after POST process completes. For computers with an OS selection screen, we start timing from the moment we select Windows at the OS selection screen. Each PC was set to automatically logon.

The timings are broken down as follows:

1. GUI – GUI appears with the mouse.
2. Desktop – Desktop & taskbar fully shown, ready to launch an application.
3. IE8 – Internet Explorer 8 with the homepage loaded and “Done” shown in the status bar.
4. Other browsers – Main window fully appears with the homepage loaded and “Done” shown in the status bar.
5. Others – Main window fully appears.

Each application is launched immediately after the main window fully appears on the previous application or until the homepage is shown with “Done” in the status bar for a web browser.

Prefetching

Windows XP and later use prefetching to reduce the OS boot up time as well as the launch time of frequently used applications. When we boot the OS, launch our selection of applications and repeat this process several times, we can clearly see the effect of prefetching. The following shows an example taken from Test PC number 2:

So after rebooting this PC 6 times and running the same set of applications in sequence after each boot, we got progressively faster results each time. Note that at this stage, we did not have Registry Booster installed, but what this clearly shows is that if we did not carry out some pre-tests, the progressive performance improvements Windows’ built-in prefetching makes would have skewed the timings.

One way of getting around this issue would be to disable the Windows prefetcher, however, as we’re trying to see how much quicker we can make our system, we left it enabled. We continued rebooting the PC and application launching the applications in sequence after each boot until we got three similar timing results and used an average of these three results as our “Before” result. We repeated this process again after the repair process and once more after the defragmentation, discarding the first two test runs immediately after cleaning the registry and registry defragmentation. This test PC #2 was the only PC where we noticed significant improvements from the prefetecher after multiple runs. The other PC’s timings stabilised after test run #3.

Test results

---

As each PC has significantly different hardware, software and usage, we will take a look at each PC individually.

Test PC #1

Our first test PC is a pretty recent build containing a Core i5 750 quad-core CPU, 4GB RAM, an OCZ Agility 60GB SSD and Windows 7 64-bit as the OS. It is in everyday use for several hours a day and has had quite a lot of software packages installed and removed since it the OS was installed, such as 5 popular web browsers, each stage of Office 2010 during its beta stage, trying out various audio/video codec packages and so on. As this PC is pretty quick launching due to its SSD and 4GB of RAM, we neglected common maintenance tasks such as cleaning up unnecessary start-up processes, disk defragmentation (since SSDs don’t need it) and so on since the OS was installed last August.

With all the software installations, removals and updates and at least 90 different applications installed at the moment, this makes this PC an ideal candidate for carrying out a registry cleaning.

Due to the speed at which most applications launch on this PC thanks to its fast SSD, we picked out the slowest to launch applications and only used one web browser (IE8) to avoid the homepage loading time skewing the results. This is the only test we limited the applications to one browser. Unlike the other PC tests, we also used a video camera so that we could accurately measure how long each application took to launch by reviewing the tests frame by frame. We also carried out 5 test runs before and after the repair and another 5 after the defragmentation.

The following is the error report:

The following are the performance results, based on the average of the 5 test runs for each test:

What is interesting to see here is that after the repair process, it took an additional two seconds to reach the GUI. However, one thing that we clearly noticed and which is even obvious from the above table is that Internet Explorer 8 launches nearly two seconds quicker, bringing the timings back to the same at this stage. Both Thunderbird and FileZilla appear to be unaffected, while Windows XP Mode improved by just over a second. The shutdown time was reduced by just over a second.

To our surprise, the defrag process seems to have offered the most noticeable improvement cutting nearly 3 seconds off the time to reach the GUI, when compared to the results from after repairing the errors. When compared to before we even repaired the registry, this works out at just under a second of time saving to reach the desktop, over two seconds by the time IE 8 finishes loading and just over 3 seconds by the time Windows XP Mode finished launching. The shutdown time improved by a total of 1.5 seconds.

Test PC #2

This computer is actually a Netbook, a Samsung N120 with the original Windows XP Home OS installation and hardware apart from a RAM upgrade to 2GB. It is mainly used while travelling and has a handful of software packages installed including Office 2007.

With its limited power Atom CPU and relatively sluggish 5400 RPM Hitachi HDD, any performance improvement would be a bonus, especially when out and about and need to look something up on the web or view a document in a hurry.

The applications selected for this test are the most commonly used on this laptop and timing has been carried out using a stopwatch. We carried out some pre-runs for the Windows prefetch to stabilise such that we had consistent timings before and after each test and then took an average of 3 test runs before and after the repair and another 3 after the defragmentation.

The following is the error report:

The following are the performance results, based on the average of the 3 test runs for each test:

Despite what seemed like a bad registry error report, we had a negligible change in performance after the registry repair and defragmentation. In the individual tests, the timings fluctuated significantly for the first few applications due to the constant HDD access as the start-up processes finish initialising, but by the time we launched VLC, the HDD activity stopped and the timings were back to within a few seconds of each other. The shutdown time improved by about 2 seconds after the repair. However, we were unable to determine the shutdown time after registry defragmentation due to the Intel graphics utility intermittently not responding during shutdown, a known issue with this Intel graphics utility.

Maybe these repairs would have helped speed up something else or prevented a potential software crash/issue later on, but from our testing, we did not experience any noticeable change after the registry repair and defragmentation apart from a small improvement in shutting down.

Test PC #3

Now we’re on to a heavily used but relatively powerful Core 2 Duo 3.0GHz office PC with 2GB RAM, which is tied in with a domain server. The OS installation is about two years old and is running the original factory installation. Over the past two years, various applications have been installed, updated, removed and so on and the start-up time has increased a lot, occasionally taking as long as 5 minutes just to boot and bring up the browser! However, the start-up time is totally intermittent, spending much of this time at the stage “Applying computer settings” before it reaches the logon screen.

Once booted, it seems to perform fine, especially after reaching the desktop. However, we’re curious to see if this intermittent start-up sluggishness is caused by some registry issues, considering there is little HDD activity during most of the start-up before it reaches the stage where the logon screen would appear.

The following is the error report:

Due to the totally unpredictable start-up times, we will look at the start-up times separately rather than the average of the three. As with the other test PCs, we set the PC to automatically logon such that it does not wait at the logon screen:

The following are the sequential launch times, timed from the moment the desktop appears. These are based on the average of three timings:

Going by the start-up times to reach the desktop, the start-up time still remains an issue with it unpredictably taking as long as almost 5 minutes to reach the desktop, as test-run #2 shows after the registry defragmentation. This issue is specific to this computer as the other computers in the office boot up relatively quick in a consistent time.

For the sequence of application launch timings measured from the moment the desktop appears, both the registry repair and defragmentation have provided a negligible change in performance, much like the Netbook test. On the other hand, the registry repair process did knock about 10 seconds off the shutdown time.

Again, these repairs may have helped improve the performance of something or prevented a potential crash or issue, but from our testing, we did not notice any change before and after the repair and defragmentation apart a shorter shutdown time.

Test PC #4

Finally, we’re testing a rather sluggish AMD Athlon XP2000+ PC, which has a 6-year old Windows XP installation and has had heavy use. We were going to test it in the current state, but with near endless HDD crunching and it being very tedious to do trivial tasks such as bring up webpages, we carried out some maintenance to improve its performance enough to carry out start-up timings in a reasonable time. These maintenance tasks include removing a large number of start-up entries using the Autoruns utility and running a deep-optimised defrag using IObit Smart Defrag.

The following is the error report:

The following are the performance results, based on the average of the 3 test runs for each test:

On this PC, the registry repair has an unusual effect of increasing the time it takes to reach the GUI. Immediately after the repair, it took about 5 to 6 seconds longer to reach the GUI. In about 8 timings before the repair, which includes allowing the prefetch to stabilise, the GUI always appeared in 50 to 52 seconds. In every test after the repair, the GUI appears in at least 56 seconds.

On the other hand, there was a noticeable reduction in the time it takes to get into the web browser with the homepage displayed and this would have been perceived as a faster PC following the repair, at least for getting on the web in IE8. For example, in the before test, it took 39 seconds for the IE8 to appear with the homepage displayed, whereas after the repair, this went down to 22 seconds. Unfortunately, it did little to improve the multitasking performance, as by the time we launched all 4 applications, the overall times were within a second of each other going by the above table. This is the only test PC where we did not get any measured improvement in shutdown time.

• Repair, defrag & restore features
• Advanced tests