Viewer Performance significantly reduced - presumably by Face re-clustering

[Tveloso]

I wonder if Bug Fix #02717 might be what's causing this new behavior in the Viewer.

Mario, as you described in this post:

    https://www.photools.com/community/index.php?msg=104455

...the performance of Face Manager is now significantly improved when it's used "globally" (its performance is no longer impacted by the background Face Matching).  But it seems now, that the Face Matching operation might be impacting the performance of the Viewer.

Prior to that change, when Face Manager was used "globally" (i.e. launched from the People View for a given Person), and Faces were confirmed there, it's performance would be significantly reduced following that first usage.  But as you explained in this post:

    https://www.photools.com/community/index.php?msg=100326

The Viewer restricts face matching to the files currently loaded in the Viewer. When you close it, face matching is done in the background for the entire database.

...and as I then learned following your explanation:

...I tried launching Face Manager from the Viewer (instead of going to the People View first),  and I found that:

• Unconfirmed Faces shown in that Face Manager Session, are only those from the files loaded into the Viewer
• Face Manager remains responsive in each subsequent session when launched from the Viewer (F4)

...and that's exactly what I need.

Previously, after indexing a new batch of files, and running Face Recognition on them, I would first go to People View to confirm all faces for the people I knew were in those photos.  Now I'll proceed directly to the Viewer, and launch Face Manager from there (which is a much better way to work!).

It seems that following this change, the Viewer is no longer doing that?...(deferring the Database-wide Face Matching).

Very often now, while working in the viewer, it "stalls" after I have confirmed a given person.  All operations there (moving/sizing Annotations, navigating between files, etc.) take many seconds to react to the mouse and keyboard entry.

[Mario]

No change there.
The problem in the Face Manager was caused because the FM reloading faces after each background reclustering, not just when reclustering was finished.

When the Viewer is open, face reclustering is still considering only files loaded in the Viewer (scope), and when the Viewer closes, all remaining persons are reclustered.

Which hardware are you using?
How many files with unconfirmed faces in the Viewer?
Logfile?

[Tveloso]

Mario, I recorded a debug log for an IMatch session where the Viewer's performance dropped significantly for a period of time.  This happened following the manual addition of a Face Annotation (it was added manually, but it became a real face, and not a manual face annotation).

Prior to this happening, I had opened Face Manager from within the Viewer, and successfully "mass confirmed" 2 or 3 people, without any performance issue.

When I reached File 145944, there was just one Face Annotation there (which did not have a person assigned yet), for a person I do not know (but that I'll need to ask someone about).  A face had not been detected for someone else in that photo, that I do know, so I added the face manually (Insert, and click, Shift-drag to create a square Annotation).  IMatch then detected that face, and assigned the correct person (Person 187).

When I confirmed that Face Assignment, the Viewer put up the "Updating Person" overlay, and it was at this point that the sluggish performance started.  It took nearly 10 seconds to navigate to the next file (via pressing the right arrow on the keyboard).  When I noticed this, I navigated back a forth a bit to verify the slow behavior (it continued to take around 10 seconds to navigate between files).

Next I went to File 145945, and added another face manually.  It took nearly 10 seconds after I pressed the [/b][/font]Insert[/b][/font] key, for the little cross-hair cursor to appear. I then successfully drew the annotation (which this time became a Manual Face Annotation - since the face was turned away).  Soon after this, performance returned to normal, and I collected the log.

I'll send the log via Email.  Hopefully it will contain something useful.

[axel.hennig]

I've tried to reproduce this, but wasn't able to.

What did I do (but as I wrote, no performance drop):

• Opened several files with unconfirmed faces in the Viewer.
• Hit F4 on a selected Face and confirmed that together with other Faces, assigned Faces to other Persons, ignored Faces, removed Faces,...
• Moved to another image.
• Added a Face Annotation for a Face that wasn't recognized and assigned that Face via F2 to a Person.
• Moved to another image.
• ...

No drop in performance seen.

[Tveloso]

Thank you for checking Axel.

Maybe it's something else going on with my PC...

[Mario]

@Tveloso Which kind of computer do you have? How many files in the Viewer?

When you look at the Performance tab in Windows Process Monitor when this happens, is something maxed out (processors, disk)?

How do you "confirm" faces? With the <C> key or by clicking the green arrow button?
Do you open the Face Manager from within the Viewer and confirm faces there? The FM has no concept of scope or in which context it is opened, it must always trigger a regular reclustering.

I tested with up to 2,000 files with 90% faces. No issues.

Just looked at your log file. For a database with less than 100K files, the performance is not that good.
Is the database on a SSD?
IMatch reports relatively long durations for face reclusters (10 seconds and more per person) and reports a category named 'XMP' as exceptionally slow. 'XMP' is calculated very often. Is the category visible somewhere?

IMatch considers how long the user interface is idle when deciding if it can add more threads for better performance for background tasks. Working with the Viewer, for example, resets the user interface idle counter, and this tells background processes to take it easy.

[Tveloso]

Which kind of computer do you have?

I use a Dell Laptop (XPS 17 9720 with a 14-Core i9-12900HK)

How many files in the Viewer?

The scope was 343 Files in a Result Window.  After running Face Detection on them in that Result Window, they were all sent to the Viewer.

When you look at the Performance tab in Windows Process Monitor when this happens, is something maxed out (processors, disk)?

I'll try to repro this later today, with Process Monitor running.

How do you "confirm" faces? With the <C> key or by clicking the green arrow button?

When confirming an individual Face, I usually do it with <C>. 

But most of the time, I launch Face Manager for an unconfirmed face, and "mass confirm" all the faces of that person there...(so that after having done this for a few files in the set, most Faces are already confirmed in all subsequent files - then it's just manually adding any missing ones).

Do you open the Face Manager from within the Viewer and confirm faces there?

Yes, almost always from within the Viewer.  I did this for several persons (confirming several 10s of faces for each), without any performance issue. 

It wasn't until I manually drew a Face Annotation (which IMatch turned into a Real Face, and assigned the correct person to), and I confirmed that face, that the issue began.

Is the database on a SSD?

Yes, both the Database and the Files, on separate SSDs.

IMatch reports relatively long durations for face reclusters (10 seconds and more per person) and reports a category named 'XMP' as exceptionally slow. 'XMP' is calculated very often. Is the category visible somewhere?

I might have had the Category Panel open, so the XMP Category would have been visible there.  I think this might be a "standard category" provided in earlier versions of IMatch? 

Based on advice given here, I previously moved the IMatch standard categories, and a number of other Data-Driven categories of my own, under a common parent that I keep collapsed.  I must have missed the XMP Category.

[Mario]

This is a more than suitable laptop for your database. There should be no issues at all.

The FM always triggers a full recluster, it has no idea of scope or that it was brought up from the Viewer. Pressing <C> or clicking he green arrow starts a partial recluster for the files in the Viewer. ~300 images is nothing. I test usually with 5,000 to 10,000 files in the Viewer.

XMP is no standard IMatch category (I'm aware of).

We need to figure out what is different when this happens on your PC.
If you can somehow find the steps, you can note the time so I know better where to look in the log file.
I have not experienced this, and I regularly test all this with a database containing hundreds of different persons, some with up to 1,000 or more images. Over 200K files in that database. And my PC is 5 years old.

[Tveloso]

Mario, I set out to try to reproduce this, while monitoring CPU Utilization.

Prior to starting IMatch, CPU was running between 2 and 4%, with the occasional small spike to around 10%:

     

After luanching IMatch, there were a few spikes as IMatch initialized (as expected), and then CPU settled back down to between 2 and 4%:

     

I proceeded to work in the Viewer as usual, but never had that extended drop in performance that I saw previously.  There were a few times where the spinning blue wheel appeared as I navigated to the next file, and then there was some flickering, and the IMatch main window actually came to the foreground, covering the Viewer (and Windows added a "not responding" to its Title Bar)...but then the Viewer came back on top, and moved to the next file as requested.  This lasted only about 3 - 5 seconds, and during this time, CPU only went into the low teens.

That happened a few times, but it was not the the same continued performance drop that led me to post this topic...(and it wasn't something that I would consider at all detremental to my work in the Viewer).

I finally saw the "Updating Person" overlay, which I thought might signal that the issue was now occurring.  But although CPU did spike to about 67% in conjunction with that:

     

...this too lasted only a few seconds.  So, bottom line, I was not able to reproduce this.

I'll keep monitoring CPU as I work in the Viewer, and if it should happen again, I'll report back.

[Mario]

Right-click into the performance monitor and switch to the per core view. This shows you if one or more cores are maxed out.

If the main window comes into the foreground and Windows reports IMatch as not responsive, some internal threads are totally blocked, which is unusual. I assume you will send me the log file of this session?

Why is your GPU (graphic card) under such a high load. 60% is unusual for normal operation, event for Intel GPUs.

[Tveloso]

Mario, I repeated the test with the per-core view.

This time the "flickering" and "Viewer / Main Window swapping" behaviors lasted a bit longer - upwards of 30 seconds, and it did appear that a few of the cores were maxed:

         

I waited until everything settled down a bit before collecting the log (which I'll send via email).

[Mario]

This is not how this should look. When reclustering, IMatch normally utilizes all processor cores to the maximum extent allowed in the current performance profile.

Something is preventing IMatch from doing that on your system. The disk is not limiting, and the graphic card, while under fairly high load, neither. So this must be something else, like expensive categories being recalculated ore something or IMatch running into a lock of sorts.

Why is the graphic card under such high load?
The Viewer will use the graphic card and DirectX, but unless you zip through hundreds of files in the Viewer, this should make only a blip on the GPU performance. Which other applications were running?

Did you have a look at the Info & Activity Panel to see what else IMatch was doing?

Which virus checker are you using and did you update your exceptions for IMatch (if any) with the new file name used by IMatch 2025.

[Tveloso]

Why is the graphic card under such high load?
The Viewer will use the graphic card and DirectX, but unless you zip through hundreds of files in the Viewer, this should make only a blip on the GPU performance.

I'm not sure what would cause the GLU Load...(this is all very much outside knowledge/skillset), but it did seem to correspond with when IMatch had "slowed down", and those few cores were maxed.

(I also don't understand why only the Intel GPU was being used - and nothing for the NVIDIA?).

I wasn't really zipping through the files in the viewer.  I would maybe move back three files (rather quickly - using the left arrow) to pick up some Face Annotations, and then move forward again, with three quick presses of the right arrow key, to paste those Annotations.  No performance problems at all doing that.

Which other applications were running?

A couple of instances of Google Chrome, a couple of Windows Explorer, a Command Prompt window, a version of Eclipse, extended by IBM (called IBM Rational Developer), and Microsoft Outlook (from Microsoft 365).

I would guess that Outlook is probably the "heaviest" of those applications?

Did you have a look at the Info & Activity Panel to see what else IMatch was doing?

I'm afraid I didn't.  I'll undock that panel and will keep it on the other display, along with the CPU monitor when I next work with IMatch.

Which virus checker are you using and did you update your exceptions for IMatch (if any) with the new file name used by IMatch 2025.

I use only Windows Defender, but I did still add an exception for the folder containing the Database, and for the IMatch executable (which I did update following the IMatch 2025 upgrade).

I need to leave IMatch for a few hours now, but I'll probably continue working in the Viewer again tonight, or early tomorrow morning.  I'll report back on how my next session goes.

Thank you so much Mario.

[Mario]

Eclipse and Chrome are maybe the applications which use 50% GPU time.
Your NVIDIA card will only used by special applications like games or applications you configure to use the NVIDIA GPU in the Windows control panel.

Maybe the log files you have sent tell me anything. I'm still working on the emails I received on Tuesday. Busy times.

[Tveloso]

I just wanted to report that I used the Viewer for a while this morning, and the "preformance drop" issue didn't manifest (despite seeing high GPU load).

Also, just in case it's in any way relevant, I wanted to mention that I usually use two Desktops, with most applications on Desktop-1, and IMatch, one instance of Chrome, and one instance of Windows Explorer on  Desktop-2:

   

After using IMatch for a little while (without issue), I decided to look into configuring the use of the NVIDIA GPU for IMatch.  I added that preference:

   

...and then did see some usage on GPU-1 (NVIDIA) while in the Viewer.  But GPU-0 (Intel) remained at high Utilization:

   

Perhaps something in DirectX is deciding to continuing using GPU-0 for some things?...(despite my having added a preference for GPU-1 for IMatch).  It's definitely the Viewer that causes that high load on GPU-0.  As soon as I exit the viewer, its usage drops to near zero.

[Mario]

IMatch ist not a game and will not benefit much (or at all) from running on the NVIDIA instead of the Intel GPU.
IMatch uses DirectX to render images in the Viewer, Quick View Panel and Slide Show. But displaying an image on screen is peanuts for modern GPUs.

You can force Windows to use the NVIDIA card for rendering, but that will not make things faster, just use more power.
The secondary GPU will be automatically used by games and AI software like Ollama. Windows will pick the fast enough Intel GPU for most things, to conserve energy.

If you play games in your browser and Windows does not automatically pick the NVIDIA card, enforcing it like you did for IMatch may make the game run faster. For all else, let Windows decide if the internal or secondary GPU is used.

Lets hope you can somehow reproduce the "slow Viewer" and we catch the reason in the log.

I've used the Viewer on my workstation and my laptop last evening and I did not notice anything. I used my 980,000 files test database with over 400,000 faces, lots of categories etc. to somehow force the issue. But I could not.

The effect you experience occasionally could be a super-slow category, or a collection or some other background task that somehow locks anything (to make even the UI freeze, which is highly unusual).