Prevent Kupfer from being pushed to swap, make Kupfer more responsive with HDD about kupfer HOT 7 CLOSED

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.

from kupfer.

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.

from kupfer.

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.

from kupfer.

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.

from kupfer.

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.

from kupfer.

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.

from kupfer.

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.

from kupfer.