Wishing an option to selectively "keep search results / branch view" tabs in memory

[autocart]

Hi Don,

as noted in other threads, the option "Cache search results" in the configuration is practically useless, since it can be even slower than a completely new / repeated search, when switching tabs back to that search results / branch view tab. This seems to be true at least for long resulting lists, where the idea of not wanting to repeat a search, would really make the most sense.

But what about keeping the whole search results or branch view tab in memory when switching tabs away from it? Then, when I come back to that tab, it should just behave as if I never left it, no delay of any sort whatsoever, right?

Of course, I understand that you might be worried about memory overflow or whatever it is called.
Therefore, the decision of whether to keep search results tabs in memory could be based on the number of open search results tabs. Only keep MAX the most recent X search results tabs in memory. This number could be specified in the config. It could also be based on the (min) number of found items. Or both, the (min) number of found items and max number of search tabs.

In the UI, similar to the "Cache search results" option, there could be an option as "Keep this number of most recent search results tabs (incl. branch view) in memory (while they exist)" (or similar) and changing the label of the input field to "number of most recent search results tabs (incl. branch view) kept in memory (while they exist)" (or similar).

And another similar option "Keep search results tabs (incl. branch view) in memory if MIN X found items" (or similar) and changing the label of the input field to "MIN number of found items to keep search results tabs (incl. branch view) in memory" (or similar). Yes, the MIN would be correct because I would want to avoid the reload/research especially with long result lists. Thus, I could have a lot of "small" searches open in the background that do not affect the memory.

Of course both options should be connected with AND. Both must be fulfilled for the tab to be kept in memory.

BTW, the search results bar (blue on top) could indicate whether those are cached search results or a memory-stored search results or none of both.
And there could be a branch view bar stating similar info.

I know, this probably would be a big change and big changes are scary so I assume it will not happen. But just as a food for thought I posted it anyway. Maybe the is a small chance that it will come one day.

regards

[admin]

I already mentioned that possibility here: viewtopic.php?p=222250#p222250

Not that scary, and technically not that hard (but it would not work across sessions because Windows always shuffles the sys icon indexes for each new process like a madman). I'll think about it. Codeword Snapshot.

[autocart]

That would be great!

(BTW, the link leads to the page "Viewing profile - admin".)

Across sessions. Sure that is another issue to tackle. What if there was another option to specify what should happen across sessions:

1. Keep the results cached
2. Repeat the search
3. Show what is shown now: "XYplorer was closed with this search open. Click the icon to perform the search now."

[admin]

Not so fast. These are just minor details that can be dealt with later. (Fixed the link)

[autocart]

No "stepping on the gas" from my side. I am just brainstorming.

So, you meant: "Theoretically, of course, XY could cache ALL metadata. It would be a bit memory hungry if you have many tabs, and it would get stale over time, but it would be insanely fast."
I originally did not understand that sentence. Yes, thank you for thinking about it.

[admin]

I have thought, I have tested, I have measured: The full cache will at best double the speed. But the price in memory and staleness is high, plus the price in support work (people will complain about stale data). So I decided against it.

[autocart]

Thank you for thinking about it, testing it, and measuring it. Thank you also for communicating your decision clearly, which is helpful.

Probably I misunderstood what cache means.
I thought you were talking about some kind of different cache than the option "Cache search results" does, but maybe that is the same after all?
In my naive mind, I was thinking you could just leave the data structure of the search results tab in the computers working memory untouched when switching tabs away from the search results tab, just as if this tab never became a background tab in XY.

If I open a 2nd XY instance with a search it is not much different. That search results tab in the 2nd instance always stays an "active" foreground tab even if the whole window of that XY instance is not visible. And when I switch the focus back to that 2nd XY instance, voila, everything is back *immediately* without *any* waiting period. But maybe this is no possible within the same XY instance?

P.S. For some reason I thought of cache as a storage location on hard disc that would survive sessions and therefore "memory" was something else for me. Yeah, now it does not make so much sense anymore.

[admin]

That's not how it is built.