[REQUEST] Cache .desktop files and their icons to speed rofi up

[Asmageddon]

Before opening a feature request

• [X] I checked the next branch to see if the feature has already been implemented
• [X] I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

In the discussion of a previous issue, I didn't see what I'd consider to be a fairly simple and efficient solution proposed, hence:

What if rofi cached not only all the used files in a single compressed archive, but also their paths and timestamps, making it possible for rofi to load everything from said cache, only updating those entries whose source files have been updated/added/removed?

How do you know that this problem exists today? Why is this important?

I run Linux off a slow HDD, and often clear memory cache with sudo echo 1 >> /proc/sys/vm/drop_caches, and rofi is close to the slowest-to-launch program on my system - rather unfavorable for a core part of my workflow.

Who will benefit from it?

It would be a godsend for systems with slow I/O, and would to some extent benefit everyone everyone.

Rofi version (rofi -v)

Version: 1.7.5

Configuration

https://gist.github.com/Asmageddon/13bd82805d84663c5cd28a75ae736c71

Additional information

No response

[DaveDavenport]

https://davatorium.github.io/rofi/1.7.5/rofi.1/#other

First option listed in this section?

Icons are loaded async and should not cause slowdown in the use of rofi (maybe in the visual bling)

[DaveDavenport]

What if rofi cached not only all the used files in a single compressed archive, but also their paths and timestamps, making it possible for rofi to load everything from said cache, only updating those entries whose source files have been updated/added/removed?

Wouldn't this just slow things down again compared to current cache?

[Asmageddon]

Wouldn't this just slow things down again compared to current cache?

Why would it? Anything that makes it possible to skip processing 99% of desktop files and start displaying options immediately after reading a few KiB from a file and then loading in the (pre-scaled maybe even?) icons from it would be a huge improvement upon whatever it is right now that takes upwards of 20s on my system.

[DaveDavenport]

Because the current system (if enabled) it only needs to read a single file, what you propose requires it to spider down the whole file system again to check for new files, compare timestaps, etc. (ignoring icons for now)

Have you tried to enable the current cache?

[Asmageddon]

I assume you mean -drun-use-desktop-cache? I was under the impression that it doesn't take changes to .desktop files into account(also why it's not the default), hence why I opened this FR/proposal.

[DaveDavenport]

Yes, hence my reply of the slow down. I tried to get the cache, if needed, as fast as possible. What I want to avoid is that if you open drun mode, things pop-in/pop-out once it is open, as this makes location where items appears in the list non-deterministic (and might change after you read the entry and navigate to it) and would (for me) screw up muscle memory. Therefor it now only opens after the list is fully loaded.

Adding code that for each entries access the file system to check if that file still exists and if it is modified might slow this down again.

[Asmageddon]

Getting file metadata should be pretty fast, though, shouldn't it? What if cache-plus-check-modification was the default, while drun mode simply used the cache without checking modification as an alternative option? Possibly updating in the background, for the next(not current, to not alter what's shown) launch of rofi?

[DaveDavenport]

Getting file metadata should be pretty fast, though, shouldn't it?

I don't know this behaves over different file systems (where is the meta data stored in relation to the files) and how much obtaining the metadata cost. I guess this needs to be bench-marked.

I would accept a patch that implements this (if it is shown it is clearly beneficial over current implementation) . For me the benefit/effort for this is to small given the absolute minimal time I have to work on rofi. We have solution for slow machines with mechanical disks that should be fast given it is a binary dump that gets loaded (ignoring icons, as they are async from rofi use).