Reduced response time in Face Manager due to prior Face Manager sessions

[Tveloso]

When running Face Recognition in IMatch, a typical approach I take is as follows:

• Run the FR process in all files in a folder (Ctrl+M,F)
• Wait for that operation to complete (no entries remaining in the Processing Queue)
• Run Face Manager for all persons I know were in the Photos just processed, and confirm new Unconfirmed Faces
• Review the files in the Viewer, to add any faces not detected (because they were averted or completely turned away)

Several Releases ago, I noticed that Face Manager became largely unresponsive (on my previous slower PC), after confirming faces for the first person. 

I am now on a faster PC, and while the issue is less pronounced, it's still present.  When I confirm faces for the first person, save changes, and close Face Manager, some 300+ entries are added to the processing queue (I believe this corresponds to the number of persons in my database).  While those entries are being processed subsequent executions of Face Manager for the remaining persons, either take a long time to open...sometimes not completely rendering some of the thumbnails (I think of newly added unconfirmed faces) for quite some time:
   


...or FM opens quickly, but then continually refreshes (alternating quickly between the thumbnails and a black background with a spinning wheel):
   


...making it difficult to confirm the faces (until the processing queue is empty again).

Sometimes this doesn't happen, but it does most of the time.

This is not really that big a problem for me, because I can easily skip Step-3 (running FM), and proceed directly to the Viewer work. 

Since my photos are usually of the same few people, and since IMatch usually creates the Face Annotations already in a confirmed state anyway, there are relatively few new unconfirmed faces for each person, and it's just as easy to confirm them in the Viewer. 

But when I process larger batches of files, and the number of newly added unconfirmed Faces is a little larger, its much better to "mass confirm" them in Face Manager, so that the Viewer work then involves only adding Annotations for undetected faces...(so most of the time, I can move quickly to the next file, when all faces are there and already confirmed).

I suspect that a major contributor to this issue may be that I still have lots of unconfirmed faces in my database, but Face Manager didn't used to behave this way, and this is a relatively new behavior (starting maybe 2 or 3 releases ago?)...

I'll send a debug log, collected while Face Manager was behaving this way, to the support email address.

[Mario]

When IMatch is processing faces in the background, assigning and removing persons to/from faces, the "base data" on which the Person Manager works is constantly changed. Tens of thousands of messages are fired on the IMatch software bus, and many of these the Person Manager has to process.

Scanning all unconfirmed faces in the database to find new/better matches based on the changes done in the FM is a complex process, utilizing all processor cores and often utilizing the database system at 100%. This will inevitably cause some performance impact on all other IMatch operations. This depends on the number of processors, processor speed, memory speed and disk speed in the user's system of course. And the number of images / faces in the database.

For features like the FM, which works with the very same data that is changed 100 times a second during this phase or the Viewer, when you add/remove/assign faces during that phase, the performance impact will be more noticeable to the user.

There is no free lunch, unfortunately. IMatch tries its best, though.
Like, while the Viewer is open, it only processes faces of the files loaded in the Viewer when you assign/confirm/remove persons from faces. This way you can see the impact of your change, but without waiting for IMatch to process all other 100,000 faces in your database.

For the FM there are no such easy shortcuts. When the system is busy, it has to wait until it can get new data.
One way would be to halt background processing while the FM is open. But then it would work with stale data, temporary person assignments to faces which will be changed as soon as the background processing queue is allowed to continue.

I can spend some time on this for IMatch 2023. See if I can somehow improve the responsiveness of the FM. Good performance in IMatch is always important to me!
So far you are the first user (AGFAIK) running into this issue, so maybe it's not that much of a problem for the majority of users.

@All Users

If you experience the same issue, please use the Like (thumbs up button) at the bottom of Tony's post to let me know.