Performance Based ‘openSUSE 12.3’ (KDE) Review

My previous encounter with ‘openSUSE’ (12.2 KDE) did not go that well, although I loved the KDE desktop, its customizability, ease of use and all that, it did not however ‘score’ that well in terms of being a stable and ‘responsive’ operating system under somewhat ‘heavy’ disk stress.

For instance, if I were to open few programs while the HDD was very busy (say while copying a large file within the same disk), then for a few seconds the whole operating system seemed like stuck, and then everything would come back to ‘live’, but it would get stuck after another few seconds.

This was what happened most of the time and it was very frustrating (obviously), although the OS did not crash or got completely out of control but finished all the jobs. Nevertheless, I blamed KDE’s I/O API (a set of tools in KDE that handle input/output operations) as being the reason.

However, I was excited to hear that the newly released 12.3 is said to have addressed many of those performance related issues (faster start-up, improved ‘Nepomuk’ – Desktop indexer in KDE, improved ‘Dolphin’ – File manager etc).

So I installed it and decided to review the 12.3 KDE version in terms of system performance improvements that can be observed by home users like you and me.

So in this review, I will not discuss what’s new with the desktop or other applications, instead, I’ll try to compare the boot-up times, initial memory usage, CPU usage at idle, power usage at idle, system responsiveness, shutdown delay etc.

For the comparison I’ll be using ‘openSUSE 12.2 KDE’ & ‘openSUSE 12.3 KDE’. I have run each of these tests at least 5 times for getting an average reading (s). And my notebook consists of the following hardware (basic details): An Intel Core i3-2330M, 4GB RAM (DDR3), Toshiba 7200 RPM (320GB) SATA HDD with Intel HD 3000 GPU (it’s a Dell Vostro V131).

Boot-up times …

Among other things, there were few that slowed down ‘openSUSE 12.2’. It had an animated boot-logo, two boot-level virtuliazation related system service that most users won’t be using & specially a buggy ‘Nepomuk’.

All together, they slowed down the OS unnecessarily. And sometimes, even the desktop finished loading, the OS became stuck for another few seconds (6-7 in my experience) and it was Nepomuk’s fault. After all these considered, the total boot-up time was 37 seconds (roughly).

‘openSUS 12.3’ however, comes with a simple & lightweight boot-logo, though the virtuliazation related services are still enabled by default, ‘Nepomuk’ has received some improvements (low memory usage etc) and now it loads seamlessly with the desktop and doesn’t make the OS stuck.

I’m sure there are other improvements that have helped, but at the end, ‘openSUSE 12.3’ booted into the desktop fully (without doing any manual tweaks) within 27 seconds! (roughly).

It’s roughly a 27% decrease, what’s can I say, it’s awesome! 🙂 (Ubuntu 12.10 however, boots in 17-18 seconds though).

Initial Memory Usage …

The other apparent conclusion one can draw from the above boot-up decrease is that the initial memory usage should also be decreased, and it is of course is the case. In ‘openSUSE 12.2 KDE’, without doing any manual tweaks, the initial memory usage was around 428MiB (this is an average value as it fluctuated a bit). But the initial memory usage of ‘openSUSE 12.3 KDE’ was around 359MiB!.

This is roughly a 16% decrease, it might not sound like much, but given the fact that KDE (both desktop and apps) are (or used to ?) a bit heavy on memory usage, this is extremely impressive in my opinion (heck, even Unity uses around 330-340MB).

CPU usage at ‘idle’ …

When a computer is idle, meaning that no process is using the CPU (this usually occurs when the user isn’t running any programs and the OS isn’t running other programs from background etc), the CPU usage should drop to zero or to a value that is close to zero.

GNU/Linux hasn’t been doing the ‘CPU idling’ that well in the past but most major distributions that I’ve used recently are doing extremely well. In ‘openSUSE 12.2 KDE’, the CPU usage at idle was about 1% and sometimes it even registered zero.

This is the same with ‘openSUSE 12.3 KDE’, but the zero CPU-usage occurs even more frequently!. So again, kudos to ‘openSUSE 12.3’ :).

Power usage at ‘idle’ …

I also measured the power consumption (at idle) on both 12.2 and 12.3. As you can see, the power consumption was pretty much the same.

ACPI (Suspend, Batter/AC & hardware detection etc) …

System suspend & wake-up times have also improved in ‘openSUSE 12.3’ and they only take around like a 1-1.5 seconds (each) which is pretty impressive!. Hardware detection is also excellent as ‘openSUSE 12.3’ automatically configured my audio, video (Intel HD 3000), webcam etc.

However, the battery and AC adapter detection isn’t that great. For instance, when I unplug the AC adapter, the battery indicator on KDE kept displaying as the AC adapter is still connected!, but indicated that system is discharging. This is only fixed if I rebooted the computer, but if I plug-in the adapter afterwards, then I’ll have reboot the PC again for the system to update the change.

This doesn’t seem like a KDE related issue and is a ‘Kernel’ bug (?) because it exists in other desktops (Gnome-Shell) as well. Other than that, I’m very happy with my battery life, fan noise and other hardware are working without any issues whatsoever.

System Responsiveness …

As I said in the beginning, the one that got me frustrated while using ‘openSUSE 12.2’ was the lack of responsiveness from the OS while doing other things when the disk was busy. But since 12.3 came with a lot of performance related improvements, I couldn’t wait to test it.

So without any delays, I started to copy a somewhat large file to a different location (on the same disk) and then through the ‘Start menu’ I tried to open few programs (LibreOffice, Amarok, K3b, Konsole etc). How did it go ?

Well, it was pretty much the same. Here & there, the OS got stuck completely for few seconds and then it came back, but went back aging to being stuck etc etc. You know, I honestly don’t know who’s to blame here, but let’s consider the following.

Whenever you deal with files (copy, move, rename …) in KDE or KDE based applications, they rely on a set of protocols called ‘KIO’ API as mentioned in the beginning. And when you copy a file in KDE, it’s handled by a process called ‘kio_file’.

It is actually not this tool that does the file copying, it just passes this job to the ‘Kernel’ (a set of core utilities that perform the actual communications with your computer’s hardware) level tool called the ‘disk i/o scheduler’. ‘disk i/o scheduler’ then passes it to the disk controller (disk’s ‘firmware’ actually) to do the actual job.

However, if any of the tools aren’t optimized properly, then the whole process can get jeopardized. For example, if ‘kio_file’ is not properly optimized, then that will influence the ‘disk i/o scheduler’ and then the disk’s firmware itself thus negatively affecting the performance as a whole.

So who’s really to blame ?

This is extremely hard for someone like me to figure out. I mean, after all, I’m just an average user and I don’t have the proper knowledge. There was however one thing that I could do, and that was to install Gnome-Shell and run those tests in it. Why ?

Well, I don’t know how it is with other desktops, but Gnome also uses an I/O API of its own. So, I could create similar situations in Gnome Shell and if the OS responsiveness is significantly improved then that probably means that it is KDE’s fault.

So I installed Gnome-Shell and logged into it. Then while copying somewhat a larger file (1.5 GB), I started to open: ‘LibreOffice Writer’ & ‘Calc’, opened a saved web page in Firefox, Terminal window (for running a program), ‘Document Viewer’, ‘Yast’ (hoping to run ‘Software Manager’ once ‘Yast’ was opened), a compressed file through the file archiver, Gnome’s control panel & searched for an app or two in the ‘Search’ box while all this was happening.

How well did Gnome Shell handled it ?

It handled it extremely well! (when compared to KDE). I mean, there were few lags here and there, but they were very short lived and more than forgivable as no OS can handle situations like those without affecting its responsiveness anyway.

In other words, I was able experience the ‘usual’ OS responsiveness that I would get under Ubuntu’s Unity desktop (even better actually!, pretty similar to the awesome experience that I had with ‘Linux Mint Nadia’) and I was pretty happy. So yes, it seems that it is in fact KDE’s fault.

So there’s nothing KDE users do ?

Again, I don’t know if all the ‘openSUSE’ KDE users experience this issue, but if you do & love KDE anyway 😉 then you won’t be ‘switching’ to Gnome just because of that, right? So, there was actually one that I could test and that is try changing the ‘disk I/O scheduler’ and see if it improves the OS responsiveness to an acceptable level.

As some of you might know, GNU/Linux includes three ‘disk I/O schedulers’. They’re called ‘CFQ’ (I think it is the most widely used one, also the default one in ‘openSUSE’), ‘Noop’ & ‘Deadline’. Ubuntu these days use ‘Deadline’ and I’ve also tested it against ‘CFQ’ (in Ubuntu) & ‘Deadline’ seems to improve the responsiveness slightly.

So I changed the ‘disk I/O scheduler’ to ‘Deadline’ (this is extremely easy to do thanks to the awesome power of ‘Yast’) and rebooted the notebook computer for the changes to apply. Then I re-ran the tests in KDE using ‘Deadline’ and it did actually improved the responsiveness. Sure it didn’t fix the issue completely, but I’d say that the responsiveness was improved by 30-35%, which is pretty decent.

So, as a faithful KDE user, if you don’t want to switch to Gnome Shell, then you can try changing the ‘disk I/O scheduler’ to ‘Deadline’ to see if it helps. I’ve also heard that ‘Deadline’ also improves the performance under SSDs as well. So until KDE fixes this issue, not all is lost :P.

___________________

Changing the ‘disk I/O scheduler’ in ‘openSUSE 12.3’ using ‘YaST’

Open ‘YaST’ control center and then from left choose ‘System’. Then from the right-side choose ‘Kernel Settings’, from the next window click on the ‘Kernel Settings’ tab and click on the drop-down menu under ‘Global I/O Scheduler’ option and choose ‘Deadline [deadline]’.

Then click on the ‘OK’ button, once everything finishes, reboot the computer for the changes to take effect. That’s it!.

___________________

There’s an another ‘disk I/O scheduler’ that is based on ‘CFQ’ called ‘BFQ’, and it is designed to specifically address some of the OS responsiveness related issues in other schedulers. I have run it in Ubuntu recently and saw that under heavy disk I/O activity, ‘BFQ’ has can improve application loading times by 260-670%!! (roughly).

‘BFQ’ is however not included in most GNU/Linux distributions (including ‘openSUSE’) but users can install ‘Kernels’ such as the ‘pf-kernel’ that comes with it enabled by default. But since ‘openSUSE 12.3’ is too new, there isn’t a ‘pf-kernel’ for it and thus I couldn’t test it.

Shutdown Delay …

This is getting boring, let me wrap this up quickly :). ‘openSUSE 12.2’ took around 14.5 seconds for shutdown, but 12.3 only took about 9.8 seconds, which is roughly a 30% decrease, excellent!.

Conclusion …

So all in all, ‘openSUSE 12.3’ might not be an awesome distro in terms of OS responsiveness (though it can be somewhat fixed), but if you’re looking for a beautiful looking, lightweight, fast booting/shutdown, efficient KDE desktop, then it is still a pretty awesome OS.

P.S: Since in this article I concentrated on the performance, if you want to know what’s new in terms of desktop applications, why not head over to this ‘openSUSE 12.3’ review by ‘Swapnil’ over at ‘Muktware’. Good luck.