Slow startup - 20 sec freeze

[FrankS]

Since a year, after upgrading to the previous version, I experience a weird behaviour. After start-up I am able to perform a few mouse clicks, then iMatch freezes for about 20-30 seconds. The iMatch screens expands vertically (getting blurry). Continuing with mouse clicks often results in Window offering to close the application or keep waiting.

Once that initial freeze is over iMatch behaves normal.

This behaviour I see in 9 of 10 start-ups (pretty often but not always). I had hoped with the 2019 version this to change, it did not.

It was never a real issue as it only affects start-up and waiting helped. Thought tofay it is worth addressing here and therefore creted the attached debug log. The pause took place between
12.23 19:59:40+   
12.23 20:00:12+32172

Maybe that helps.

Until then, I get omething to drink after starting iMatch ;-)

Thanks
Frank

[Mario]

Your database is tiny and loads in 10 seconds.
Run a diagnosis and optimize from the Database > Tools menu for starters.

Then show us which panels you have open. If you use a custom File Window layout etc.
Maybe you have many expensive panels open (Filter Panel, Category Panel) which force IMatch to recalculate all categories and collections right at the start.
For a 40K files database this should not take long, but maybe your virus checker or something is slowing down IMatch?

I don't see unusually slow operations in the log file. IMatch only reported the database load, but that's normal. 10 seconds is OK-ish for such a small database. Not really fast, but OK.
Is this a workstation PC or a notebook? SSD? Folder containing the database (!) configured as an exception in your anti-virus?
90% of all "IMatch is slow" cases is caused by virus checkers these days.

[FrankS]

Thanks Mario for the fast feedback.
Will try the AV exception and report back.

[FrankS]

Had added and AV exception to the database file, no change in behaviour.
Extended extension to the complete where database is stored, no noticeable change.
Also added an AV exception to the pictures folder, somewhat better, freezes less often.

What is annoying (never noticed before) is that the picture viewer takes a while to show some pictures, 10-20 seconds.

Debug log attached.

[FrankS]

... and my work screen with panels ...

[Mario]

Your log is not complete and does not tell much. Please attach a complete log file from a session where you loaded files into the Viewer and it took 20 seconds.

At the start of the attached log file fragment, IMatch reports that loading a simple JPEG from the cache takes over 10 seconds (!) on your computer.
C:\ProgramData\photools.com\IMatch6\previewcache\1F4DB1EC-4AA5-4506-8F7C-70AFD2B92189\24\2496.jpg
Normal is something between 0.1 and 0.3 seconds - even on computers five years old or notebook PCs.

Something is badly interfering with IMatch and Windows, because IMatch loads the images from the cache with native Windows WIC/DirectX functions directly into the graphic card.
When Windows takes 10 seconds to load a JPEG, something is definitely wrong on your system. Virtus checker, some background process etc. Maybe try a clean boot, close/disable background processes, disconnect from the Internet and temporarily disable the anti-virus (unless you use Windows Defender, which usually never causes issues) etc.

If setting the folder containing your images on the exception list results in better performance, set the cache folder (Edit > Preferences > Cache) also on the exception list for a test. Maybe this solves the 10 seconds per file load times...

[FrankS]

Hello Mario,

the startup freeze persists.

In the meantime I reinstalled all graphics drivers.
Attached a new logfile. The AV scanner was turned off. Started the application. Went to one category folder with 5 or so entries, each just a few photos. Then used the cursor up/down keys to just navigate between these 5 folders. After a short while iMatch freezes for about 40 seconds this time.

Important to know is that this happens *only* the first time on a day that iMatch is started. Closing and re-opening it (waited up to 2 hours) does not trigger the freeze. Next day, back.

I think AV scanner and graphic drivers can be excluded, also because no other of my applications is having an issue.

As the update check result always appeared after the freeze I had disabled the check. I understand it then happens only once a week and not at each startup. But the freeze still happens.

Is there any other test you suggest I can do?

Frank

[Mario]

This is a very small database.
It has less only 40K files. Still, it takes 10 seconds to load. Not really snappy, but not bad either.
Is D: a spinning disk or an SSD?

The log is not in debug mode (Help menu > Support > Debug Logging) so the information is only minimal.
I see that IMatch does nothing between 19:10:41 and 19:11:20. During this time the File Window is loading, but I cannot tell how many files are loaded, if categories need to be recalculated due to missing debug mode info.

If this happens only once per day or only once until you restart the system, the problem is most likely the disk.
If the database has been opened once and all data cached in the Windows file system, Windows delivers the data from the memory cache and no longer needs to access the disk so often.
This means when IMatch needs to load data from the database, Windows can deliver it much faster.

This could be a real slow disk, a virus checker scanning the database (did you make folder (!) containing the DB an exception, and IMatch as well?)
But for a small 40K database, the Windows file system should pull everything into RAM in the pre-fetch. IMatch uses only 400MB RAM tops, so there should be plenty of RAM for Windows to use for caching...

Enable debug logging and reproduce this. Maybe we can then tell more.
When IMatch is starting it has to calculate categories and collections, depending on which panes you have open. This can mean a lot of activity and disk reads, since none of the data is yet cached and everything depends on the speed of the disk. Is D: your fastest disk?

[FrankS]

Thanks Mario,

iMatch is in Debug Logging since I started this thread! So what you see is the Debug Log. I get a warning that debug logging is active each time I start iMatch.

Drive C: is a SSD
Drive D: a standard harddrive
Drive P: contains the photos and is a partition on the same HDD as drive D:

I will run some performance tests against drive D:

Worth noting may be that the freeze issue seems to always appear 30-45 secs after starting iMatch. Until then all works fine, and afterwards.

Before starting iMatch the AV scanner is disabled for 10 minutes, but on or off has no influence on the bahaviour.

[Mario]

Yes, debug logging was on. Nothing was logged, still. So IMatch was forced to wait on something external for 20 seconds. Very strange. Slow disk, most likely.

As outlined in the IMatch database help topic, ALWAYS put the IMatch database on your fastest disk. Which means of course your SSD.
You should get a VERY noticeable performance boost by moving your database from the D: disk to your SSD.

[FrankS]

OK, have moved the database the SSD. The freeze is just there, it just happens faster. Around 7 seconds instead of 40 seconds as the logfile shows (12th last line in attached file). That matches the performance difference between two drives which I also measured.

It is still puzzling that this freeze happens at all. iMatch does so many things nicely in the background not interfering with the user interaction, but then there is that one miracolous thing blocking the user. Anyhow, while not resolved I can live with the workaround resulting in being only 7 seconds bothered. Thanks Mario.

A side effect of moving the DB to the SSD is that the backup is suddenly almost halfed in size (see screenshot). In the first backup after the move I had forgotten to specify the DB, hence the very small backup file. I normally just press [OK] and did not notice the field was empty. Found it surprising the backup is much smaller.

[Mario]

Maybe your panel layout and file window layout forces IMatch to perform a lot of calculations in the background?
If your file window shows category colors or the category panel is open or the filter panel is open, IMatch may be forced to calculate things in real-time, blocking the UI until the data is there - because it is needed to update the UI...

All I can see in the log is that the FW is is taking 6.7 seconds to load all the data required to display 37 files.
But that does not mean much. IMatch may need to re-calc all data-driven categories, formula categories and all collections to show the data in the file window. Since at this early stage, nothing is cached in memory and everything must be loaded from the database.

Nothing can be cached because the data is still on the disk. That it is now much faster just tells us that your SSD can deliver the data needed by IMatch faster.
Since your DB is now in a new folder, make sure to make this folder an exception in your anti-virus. 90% of all "IMatch is slow" reports are caused by AV interference these days.

Close unneeded panels. Use the "Thumbs only" layout.
Close and restart after every change.
See if this avoids the delay - and what exactly causing the short 7 second delay.