Prevent Kupfer from being pushed to swap, make Kupfer more responsive with HDD

[eternalbit]

Environment

Kupfer Version: 321-2 Window Manager: Desktop Environment: Linux Distribution:

Actual Behaviour

When invoking Kupfer there's a lag after the first letter is entered (I think). Files are read from HDD (audible). Then after a second or two the input field becomes responsive again and accepts further key presses and Kupfer shows its final results.

Expected Behaviour

After being invoked, Kupfer immediately responds to pressed keys and immediately shows results.

Explanation

The issue is obviously that my system has too little RAM (4 GB), otherwise the files used by Kupfer could just be kept in file cache and Kupfer would respond instantly.

Since I cannot simply upgrade the RAM I want to implement a workaround by regularly loading the files needed by Kupfer into RAM with some cron job. (I'd just let it execute some cat XYfile >/dev/null every 2 minutes or so.)

The question is: which file/s do I need to access like this for Kupfer to respond more quickly?

I tried monitoring Kupfer with strace but still couldn't figure out which files I need to cache.

[KarolBedkowski]

You can try:

1. disable unused plugins
2. switch off "Show only existing documents" in "Document" plugin configuration
3. Reduce number of "Indexed folder"
4. and never add to indexed folders network shares, cdrom, floppy etc
5. not put link to networks shares, cdroms, floppy etc in indexed folders (as read metadata may need to access this devices)
6. run in debug mode (--debug argument) and see what Kupfer waiting on.

There is no list files that Kupfer open and you can simple cache. Usually Kupfer spend time on looking for files in some directories. Some plugins need load some files, but usually it is in background.

I guess. rather upgrade hdd to ssd may help.

[eternalbit]

Thank you.

1. My active plugins are: Applications, Deep Directories, Documents, Quicksilver Icons
2. I'll try that
3. I'll try that
4. not the case
5. probably not the case
6. I'll try that

My impression is that whenever I have to wait on Kupfer, it's because of the Applications plugin loading the application list.

Maybe I'll find a way to cache the app icons or similar.

Upgrade to SSD would surely help, yes. But I'd rather fiddle with the software to solve this.

[KarolBedkowski]

System cache .desktop files with application icons when necessary. Applications icons may be located in various places (usually in /usr/share/icons, but may be somewhere else).

Problem is rather in 'Documents' plugin - because recent documents are bound (i short) to applications - show each application leaf require check for recent documents and this may take time. Please disable Documents plugin and check.

Kupfer itself don't use to much memory. As far I remember 2GB ram is enough for kupfer with debian/xfce and normal task. And it simply work fine.

[eternalbit]

Thanks.

I've disabled 'Documents' plugin now. Will see if the issue is gone then.

How about a different way to approach this: what if I try to invoke Kupfer regularly (every 2 min) in the background (so without the UI showing up) in such a way that it needs to fetch the data so that it's cached again (if for some reason it's been pushed from cache since the last time)?

I know Kupfer can be run from command line and I already tried running the kupfer --no-splash as a cron job, but this doesn't go as far as caching the files that are accessed during a query.

I'm not too firm with Python. How would I (from command line) run Kupfer or maybe just some Python function that belongs to Kupfer (without GUI) to simulate the down key being pressed in the GUI (which makes the list appear in Kupfer GUI). I think this might trigger the reading/caching of enough files, so that next time I really open Kupfer, it'd already have all needed files and be responsive instantly.

[bluss]

Hi, Kupfer has this model: sources listen for change notifications if applicable, and if anything changes, they mark themselves as needs-rescan (but do not eagerly rescan).

For example, the home directory is a directory source, and if any file changes in the home directory, that source is marked for rescan. (The home directory is a common cause for behaviour that you describe, lots of processes might change hidden files there.)

These sources that are "marked for rescan" will rescan eagerly and synchronously the next time you search, so you'll have to wait for rescan of for example your home directory if anything changed there recently. This rescan happens "on your keypress", more or less. To reiterate, the old index of that source is never used if we already marked the source as needing rescan.

It would of course be good to do something about this model. I don't believe we do source update in the background, apart from the full rescan every hour.

[eternalbit]

Problem is rather in 'Documents' plugin

Appears to be correct. In my case the lag that occurred before is indeed now gone, since I disabled the 'Documents' plugin.

Just turning off this toggle here, did not help in my case:

2. switch off "Show only existing documents" in "Document" plugin configuration

Interestingly, I still have the 'Deep Directories' plugin active. I would have thought that this plugin might lead to even more scanning and disk access than the "Documents" plugin, possibly causing lags, since it catches quite a wide scope of files (my setting: ~/ dir + 2 levels), but this doesn't seem to be the case.

[eternalbit]

It would of course be good to do something about this model. I don't believe we do source update in the background, apart from the full rescan every hour.

Thanks for your explanations.

I still don't quite understand how/why the "Documents" plugin causes the lag in my case. But for me the "solution" to just disable it (since I don't need it urgently) and instead use the "Deep Directories" plugin, is fine.

To me it's always beautiful when applications run/react fast even with a HDD but I do understand that this isn't all that relevant for most people nowadays, as almost everyone is running SSDs.

So there's no need to change anything about the inner workings of Kupfer from my perspective.