On Wed Jan 29 04:57:53 2025 +0000, Adam Rehn wrote:
Removing this field and its associated checks would result in flushing the cache every time the scan is restarted, regardless of whether the mask has changed. This would represent something of a departure from the existing approach to caching, which is to reuse the cache wherever possible. Given that flushing the cache involves making an RPC call to the Wineserver, there is the potential that a minor difference in behaviour here could have meaningful performance implications for applications that restart scans frequently (particularly if applications do so concurrently from multiple processes or threads, resulting in contention over the Wineserver RPC call). We'll conduct some performance analysis to determine the impact on relevant workloads and post the results here to inform further discussion.
Adam, agreeing on these remarks. Real life impact would however vary from usage of rescan (between restart keeping current mask vs use a different mask). Out of curiosity, do you have some figures to share here from your current test cases?
My thoughts behind the question deals in fact with the data structures used... I wondered if the mask should be part of the cache, or part of an iterator on top of the directory view (meaning that the cached directory view shouldn't be filtered by the mask). That would cleanly separate iterator operation (restart, set a different mask) from flushing the cache entry.
But that would have other impacts. So I'm not considering it for this MR.
So ok to keep the mask inside the cache entry.