Prolonged Category Refresh And Render Cycle

[Darius1968]

I've been dealing for some time now, with there being about an 8 sec. delay, from the time that I switch back to categories view from any other view, which seems to be triggered by certain use case scenarios. 

More specifically, I'm attaching "Category-Refresh-Cycle.zip" to this post, which details what happened when I just did MD (Description) and file name changes to said file, followed by a MD write-back, while in Collections>Pins>Red view.  Those MD changes created no problems as I could switch to categories view with no hangs whatsoever. 

However, I then switched back to collections view, and here, I simply removed this file from just one category.  This creates the problem because when I now switch back to categories view, I'm presented with about an 8 sec. delay, during which IMatch is frozen with the spinning hourglass, until the program is again responsive. 

This scenario of IMatch hanging for 8 sec. - whenever I switch back to categories view from any other - lasts until I close-and-relaunch the database.  So, the attached log file is provided to troubleshoot this.  Thanks. 

[Mario]

Removing a file from a category invalidates all other categories that may depend on that category, requiring all categories visible somewhere, e.g in the Category View to update.

Your database reports ~ 360,000 files and about 15,000 categories. 
The only "slow" operation IMatch has logged is opening the database, which takes 10 seconds.

The File Window reloads in typically between 50 and 70 milliseconds.

In the log, a file is written, many collections are recalculated, taking between < 10ms and 100 ms.
A search for metadata tags is active, searching for the regular expression ^True in the entire database.
File Histories are recalculated.
Another metadata search is running, for "non empty", entire database again?
Apparently you have some categories which use @MetadataTag and these categories need to be recalculated. For a database with almost 400,000 files and probably as many values per tag this will take some time. It runs 99% in the database and maxes the database out and slowing down other tasks in IMatch requiring database access.
For example, for one of the queries required to update a single category, IMatch fetched 360,751 result entries...

Try to collapse/close the "IMatch Workflow Categories" category. This avoids the expensive categories to be recalculated all the time. If you have created your own expensive categories using @MetadataTag or similar, hide them under a parent category and keep it closed.

Remove categories you don't need. Since this is all mostly I/O bound (IMatch waiting for data coming from the disk), double-check that your virus checker is not interfering with IMatch (unless you use Windows Defender, which does not make problems).

Check for other applications running at the same time as IMatch and check if these require a lot of disk I/O.

That's pretty much all I can tell. IMatch has not logged any unusually slow operations (things taking more than a few seconds), no "slow" categories are logged etc. No operation taking more than about 500 ms. is logged.

[Darius1968]

The given scenario is happening even when all categories are collapsed. 

I went ahead and deleted all my workflow categories, thinking this may help solve the problem.  It may have shaved a few seconds off the time needed to open my DB, but nothing else. 

A search for metadata tags is active, searching for the regular expression ^True in the entire database.
 Another metadata search is running, for "non empty", entire database again?

The only place I could find anything like this was in one of the workflow categories, and I have deleted all of them.  So, can you be more specific - from the log file - where this search is? 

[Mario]

If you have deleted the Workflow categories, these categories will no longer be updated and the metadata search will not be needed anymore. You can search your log file for ^True to verify.

No other idea about your delay issue. Nothing is logged that takes < 500ms. No unusual delays in the timeline, no warnings or errors.
Did you check your virus checker and made the database folder an exception? Other application activity maybe slowing down disk access? I have a database with a million files and more than 30,000 categories that performs superbly.