Background process makes imatch unresponsive

[Carbo69]

I have a problem with IMatch whose interface sometimes no longer responds when manipulating files.

Here are the 2 maniputions where I observed slowdowns.
- I display photos in the viewer in full screen. I display 4-5 and I mark 2 for deletion. I get out of the viewer and back to the main screen I ask to delete the marked photos. I see at the bottom right a process running (IMATCH6_LOG).
- I display photos in the viewer in full screen. I display 4-5 and then return to the main screen to stack them.
Ditto a process in the background is launched (IMATCH6_LOG-2)
From time to time I see "matching faces" or "updating persons".

Do you have an idea of the process or my configuration that could be problematic ? because it is very penalizing.
When I browse files from the main screen, the background processing makes the screen refresh and return to the original position.

Thanks !

[Mario]

Your database has about 130K files. A medium-size database.

Your system reports 12 processor cores and 32GB RAM.
That's quite beefy. You should not see any slow-down in IMatch.

IMatch reports that your categories "6_developpement", "5_infos comp", "2_A tagguer v0", "4_note" and several others are all performing very poorly. What type of categories are these?

Also, IMatch reports that collections are calculating very slow. For a database with about 100K files this is very unusuual.

Is this a notebook? A regular PC? A workstation-grade PC?

It seems that database operations the database system is not performing well.
Is C: a SSD disk or a regular spinning disk?

From time to time I see "matching faces" or "updating persons".

These are very disk- and database-intensive tasks. Again, the database system is not performing well on your PC.

Unless you use Windows Defender only: Did you make an exception for the folder containing the IMatch database in your virus checker an exception? In 95% of all "IMatch is slow" reports, the virus checker is the culprit.

[Carbo69]

Thanks for your quick answer !

My PC is a regular PC, database is on a SSD.
I'm using windows defender only and I've added "C:\Users\xxx\Documents\imdb" as an exclusion (also imatch2021x64.exe file and process)

My categories are mostly based on formulas (for example: "4_note" is based on label "@Collection[Label|3_V0_ok]")

[Mario]

Then why is your PC performing so slow that IMatch basically has to report all your user-defined categories and many collections as "slow". This is very unusual. I expect these messages to see when I run a database with a million or two million files, not with a database that has only 130K files.

[Carbo69]

That's the whole point of my message "why imatch performing so slow on my PC ?"
I even run a SSD benchmark to be sure that my disk was not faulty and it performs very well.

Is there a way to know what imatch is doing in the background after deleting / stacking files ?
Is there a way to disable these processes ? For example I don't need Imatch to update faces on the background. Once in a while launched manually is perfectly fine for me

[Mario]

The Dashboard (Performance Panel) enabled shows CPU and memory usage of IMatch.
IMatch has many background tasks which run all the time. Updating categories. Updating collections. Doing face recognition.

Your PC reports 6 CPUs and 12 cores. Running face recognition on a few of them will not harm. You usually wont even notice this. IMatch only performs background face recognition when you add or move a face annotation, or assign a person to a face. This requires updates to the internal face graph.

Have you checked all the categories which seem to take a long time to update?

Keep in mind that every time you make a change like rating, label, metadata update etc. IMatch must recalculate many or even all categories. If you have created 5 or 10 categories (search the log file for SLOWCAT to find them) which each requires a very long time to update, things can slow down a lot. Updating categories requires a lot of database read / write and also uses multiple processor cores.

Try to set the reported categories to manual update (if they are data-driven) or move them under a parent category which you then collapse in the Category View, Category Panel and Category Filter. This avoids too many updates.

The standard "IMatch Workflow Categories" set of categories all use metadata formulas. But none of them is listed as a SLOWCAT in your log file. Which makes me think that the categories you have created do really complex stuff, maxing out the SSD for a long time for every update. There are 12 processor cores but only one SSD...

I have a 12 core PC and the database is on a m.2 SSD. I can work fine with a my largest test database with 930,000 managed images and videos and 350,000 faces, 30,000 categories etc.

A database with 130K files like yours should perform well. The majority of IMatch users manages between 100K and 200K files now. Commercial and institutional clients between 200K and 500K.

The problem seems to be that the disk cannot deliver the data fast enough or that it has to do too much.
Are there other applications running which produce a lot of disk I/O?
Usually effects like this are caused by a virus checker constantly scanning the database, bringing IMatch down to a crawl. But Windows Defender is usually no problem.

You can switch IMatch to debug logging via Help menu > Support > Debug Logging.
This produces bigger but more detailed log files.

[Carbo69]

Indeed, it is probably my categories that are problematic.

I had already put them in parent category collapsed but it s the parent that refreshed with the counters.

What I just did is to pass the parent category in "direct assignment=yes" which allows to no longer have a counter on it.

From the first rapid tests, it seems to improve things

[Mario]

Very good. I forgot to mention the "Direct Assignments Only" in my suggestion, sorry.
The "IMatch Standard Categories" and "IMatch Workflow Categories" use this trick.