Since I started using KDE, I was never sure whether Desktop Search and background file indexing is something I should enable or not. Indexing is said to speed up searching and other KDE components, but on the other side consumes a lot of CPU / memory / disk space... making it a tough choice. KDE 4.11 had Nepomuk, but I noticed that 4.12 replaced it with Baloo. Since I was bored today, I decided to try enabling it on most of my drives, where I can say I have quite a bunch of files.

My experience doesn't seem to be as drastic as other users reported. Such as crashing the login session or even causing a Kernel panic. Still, baloo_file did constantly eat 100% of one CPU core for 10 minutes straight. After that stopped, a baloo_file_extractor process pops up once every minute, uses a bit of CPU, then disappears.

This doesn't seem to affect performance noticeably, but also doesn't feel too good. And since it couldn't be disabled in 4.12 (I use 4.13 where that's fixed) many people were outraged and posted negative comments about KDE on various websites. This sucks as KDE already has a reputation for being slow and requiring high end hardware.

So I was curious if Baloo is or can be made to not decrease practical system performance at all. Does Desktop Search really slow things down, or only causes scary CPU numbers to pop up? I'm thinking of the process working only when other processes don't need its CPU... so Baloo pauses if I'm running an important program that needs to use 90% CPU for example. This is rather important to know, as I wouldn't want it to slow down high-end games and the like. Checking the CPU priority of baloo_file in KSysGuard, the process does seem to be near the bottom by default, which looks like a good start.

Additionally, I was going to suggest adding a "max CPU usage" slider in the Configure Desktop -> Desktop Search menu. Where for example, if you specify 20%, Baloo can never use more than 20% CPU at any moment. Would that be useful and possible to add as well for extra safety? Although I think an even more important slider might be the drive space it's allowed to use for indexing. It doesn't seem to take up considerable disk space for me, but people with a lot more files might find that helpful.

Baloo shouldn't impose on system resources - that initial burst of CPU activity was probably it either building the list of files to index, or it performing the initial indexing process. From a user perspective, it shouldn't decrease system performance.

It is likely causing "scary numbers" to show up - a system which is fully utilised can still be very responsive as the Kernel is capable of scheduling CPU time between processes as necessary. Limiting the "maximum CPU utilisation" wouldn't be helpful (and likely isn't possible) - however it could only index when the system is idle (I think it already does this).

After running it for several days, I believe I can answer this question as well. Sadly, there does seem to be a small decrease in performance with Baloo enabled. Primarily there are two problems:

- As discussed here, the way Baloo indexes files causes the Kernel to fill the RAM with inode / dentry caches. While seemingly harmless, I don't feel comfortable with + 1GB of unused RAM appearing out of nowhere within a few hours. This can at least cause trouble if I start up a program that uses a lot of RAM and could use that free memory. I'm quite concerned about this really.

- The idle 100% CPU usage of one core every now and then does appear to make a difference. When Baloo does that, some applications appear to noticeably open or work a bit slower. I was hoping the low CPU priority would fix that, but maybe the Kernel doesn't have time to react before a performance decrease is noticed?

My own verdict is that Baloo is safe to use, but don't expect your system to be as fast if you do. It's a choice between having file indexing or a super fast system. I hope more performance improvements can be made in time to remove the need for this choice and let users have both.

The filling of RAM is a totally safe process. In terms of RAM utilisation, please use KSysguard's "System Load" tab to get an accurate reading of memory usage, as it excludes buffers and caches. The usage of buffers and caches by the kernel is totally normal - any I/O intensive process will cause these to become filled. As stated, the kernel will flush these as needed for applications (in the case of caches this is instantaneous).

In regards to the 100% CPU utilisation, how long does this persist for?

bcooksley wrote:The filling of RAM is a totally safe process. In terms of RAM utilisation, please use KSysguard's "System Load" tab to get an accurate reading of memory usage, as it excludes buffers and caches. The usage of buffers and caches by the kernel is totally normal - any I/O intensive process will cause these to become filled. As stated, the kernel will flush these as needed for applications (in the case of caches this is instantaneous).

In regards to the 100% CPU utilisation, how long does this persist for?

I am looking in KSysGuard, in the System Load tab, "Memory and Swap history". That graph is where I see the increased memory usage.

And baloo_file or baloo_file_extractor using 100% or less of a CPU core happens once or twice every minute or so. But that seems to happen forever.

Is it possible you have files regularly changing within your home directory?
As for memory usage, to be sure it is actually higher, please compare when using "free -m" or the separated figures provided by "top" (or for a more graphical form - htop).

bcooksley wrote:Is it possible you have files regularly changing within your home directory?
As for memory usage, to be sure it is actually higher, please compare when using "free -m" or the separated figures provided by "top" (or for a more graphical form - htop).

Baloo is set to index folders where I make regular changes. But by regular changes, I mostly mean modifying a file now and then, or adding a few new files every few hours. So nothing as intensive as moving 10000 files at once so it has to re-index all that.

Please follow this guide - http://community.kde.org/Baloo/Debugging - and figure out which are the offending files which are causing very high cpu usage.