SURVEY__scrolling in thumbnails__waiting period

[khfnet]

Dear IMatch-user,

how long you have to wait (after starting DB)
to sroll smooth and fast
in a jpg-prieview of

500
1000
5000
10000

Some guys have problems, but I guess it is normal to wait a little.
Please answer.

[Mario]

Which file window layout do you use?

Some users have layouts which use 10 different variables (slower), others use layouts which display almost no data at all (faster).

When you scroll, IMatch needs to load data and thumbnails from the database. If the data is not already cached in memory, disk performance is what defines how fast you can scroll. It's also important to know on which kind of disk your database is etc.

If you have a performance problem with IMatch, always include your log file. This will tell us how large your database is, how long it takes to load, if and which routines perform slow etc. Switch to Debug logging under Help > Support to include as much info as possible in your log file. Then ZIP and attach to your reply. Without a log file, everything is guesswork.

[cytochrome]

Hello Karl,

I closed IM, then started again, went quickly to my "has gps" data-driven category (around 18000 files), the photos were unfiltered, so it was a mixture of Nef, Rw2, Mrw and jpgs.
I could scroll immediately at "full" speed with the mouse.

It is a Logitech Anywhere MX like yours, so the mouse hardware is probably not a problem. Drivers? memory? cache settings?  (I looked at a mixtures of raw -cached- and jpg -normally not cached in IM-.

My PC is an I7-4770 3.40GHZ with 16 Go ram. The DB is on a fast USB3 memory stick and the files on an internal Seagate Barracuda 3 To 7200 rpm (not sure that it really matters).

Francis

PS Just saw Mario's answer. My file window layout is minimalistic, 4 variables and only version icons, so minimal stress on the system if I understand well.
PPS Normally I display only 3 thumbs per row. I switched to the "small thumbs" layout, about 8 thumbs per row and 48 on screen: the scrolling is definitely slower. After some 20-30 secs it is again flying (the mouse in super fast mode) for some hundred thumbs then slower again.

So it might be a limitation of the system/iMatch interaction. Showing hundreds of thumbs is of course much more intensive than flying through text.

Anyway, IM appears to be still much faster than displaying and scrolling through 400 jpg thumbs in Irfanview for example. On the other hand FastPictureViewer seems to be really faster than IM, but it doesn't do the same job.

[sinus]

Here too.
Like Francis, I have a mix of images, nef, jpg, tif, psd, docs ....

I have 10'000 images quite a lot of variables used in the layout, but I can scroll throug my images at very, very high speed. I do not know, can I say full, but I see not pauses or so.

[cytochrome]

Sinus,

I made a PPS... My tests were with my normal diplay, only 3 thumbs per row. But it slows down if you display a lot of small thumbs. It flies through the first few screens but then it clearly slows, remaining however quite workable (this is subjective of course).

Francis

[JohnZeman]

My database has about 50,000 JPGs.  When I click on @All to see all of them, it takes about 1 or 2 seconds for IMatch to show some of them in the file window.  Then when I scroll, it's very fast.

I don't have a lot of information in my thumbnails, filename and location metadata primarily.  Plus the category bar.

[Mario]

But it slows down if you display a lot of small thumbs. It flies through the first few screens but then it clearly slows, remaining however quite workable (this is subjective of course).
Francis

About the file window load/display logic:

The file window loads thumbnails and metadata in the background from the database. If you scroll faster than the background task can read the thumbails and metadata from the database, the file window will slow down. If you wait for a couple of seconds, the background thread catches up and scrolling will be fast again. Once the data and thumbnails have been loaded, they are kept in memory until you make changes which require IMatch to reload the data.

The problems of the OP seem to come from IMatch being unable to load the thumbnails/data fast enough. Without a log file I cannot see more. The typical tips help:

+ Keep the database on your fastest disk
+ Disable virus checker for the folder containing the database (not only the database file itself!)
+ Run a Compact & Optimize once in a while, especially when you have added/removed or updated many files.

[khfnet]

The problems of the OP seem to come from IMatch being unable to load the thumbnails/data fast enough. Without a log file I cannot see more.

here ist the logfile
processor setting has been changed from 0/0 to 1/1

[Mario]

No file attached?

[khfnet]

here it is really

[attachment deleted by admin]

[Mario]

The database system reports physical damage to the database file.
You should get corresponding error messages when you start IMatch.
Since the database has only 600 files, please re-create it.

How did you damage the database? Did you have disk problems? Power failure?

[joel23]

Dear IMatch-user,

how long you have to wait (after starting DB)
to sroll smooth and fast
in a jpg-prieview of

500
1000
5000
10000

Some guys have problems, but I guess it is normal to wait a little.
Please answer.

Times varies depending on the disk the DB was started from by double click, but maximum 60 seconds with 22.400 files.
Including the time Mario mentioned to catch up.

The file window loads thumbnails and metadata in the background from the database. If you scroll faster than the background task can read the thumbails and metadata from the database, the file window will slow down. If you wait for a couple of seconds, the background thread catches up and scrolling will be fast again. Once the data and thumbnails have been loaded, they are kept in memory until you make changes which require IMatch to reload the data.

I made some tests the other day. See attachment.

[attachment deleted by admin]

[khfnet]

The database system reports physical damage to the database file.
You should get corresponding error messages when you start IMatch.
Since the database has only 600 files, please re-create it.

How did you damage the database? Did you have disk problems? Power failure?

Yes i get error message, but only at first trial to start Imatch.
Second trial it opens with no message and no problems.
(by the way:  I don't know how to insert the error-window in the post)

If I remain well, I could start Imatch bei press ctrl without database, but it doesn't work.
So I cannot choose the second db (also test-db).
So I start IM two times with the last opend, crashed DB and then change to the other.

I never had diskproblems.
It could be, the laptop has gone into sleep at rest of 5% accu-power and Imatch was still open.
Next day continued with power supply.

[Mario]

I'm not sure about "start twice" trick, but a damaged database is a damaged database. You need to restore your last working backup or start fresh.

Going into sleep or hibernating is no problem. I do that all the time (I boot my systems maybe once a week, and always keep IMatch running). But if there is a driver problem or something, and IMatch is writing data to the disk while Windows is shutting down, it may happen that data is not flushed to the disk, but Windows signals "done" to IMatch anyway. The database system then considers the data as written, but it fact it never reached the disk. Result: Database is damaged "somewhere". Such subtle issues may never show with normal applications, but a database system like IMatch, which reads and writes data all the time, may be affected if Windows is unable to flush data to the disk.

Since this happened once on your system, it may happen again  Please go to Edit > Preferences > Database in IMatch and enable the "Default" disk write mode. This mode is a bit slower than the standard write mode because it flushes data to disk more often, and waits for Windows to write it to the physical disk and then report back. This costs performance, but is safer in 'shaky' environments like laptops which have potential problems when going to sleep or hibernating.

When you want to start IMatch with the Advanced Startup Options, double-click on the desktop icon and immediately press and hold the <Ctrl> key until IMatch displays the advanced startup dialog.

You can also open another database from the Database menu at any time of course.

[RalfC]

The disk acccess times vary greately between different setups (without any specific order):

• Raid vs single disk
• HD vs SSD
• rpms of the HD (15000 vs 10000 vs 7200 vs 5400 vs 4800) [not an issue for SSD]
• Data transfer rate, depending on the Interface for the HD/SSD: SATA (with different maximum speeds of the interface) vs ATA vs USB2.0
• ability of the drive to reorder the commands in such way that the data can be delivered quicker (command queuing and reordering: NCQ), which also needs to be enabled in the driver (AHCI vs normal)
• how full is the hard disk / location of the data on the harddisk (outer tracks are faster than inner tracks) [not an issue for SSD]
• etc

All these things have an impact how fast IMatch will be able to load the thumbnails from the DB.
Like Mario wrote, if the thumbnails can not be loaded fast enough the scrolling will throttle in the beginning until all (needed) thumbnails are loaded...

I never had diskproblems.
It could be, the laptop (...)

Do you have a normal HardDisk (no SSD) in your Laptop? The Harddisks meant for laptops are optimized for energy consumption (so that the battery usage is longer) which means that the speed of the harddisk is rather low. This than cause a slow loading of the thumbnails from the database.

Regards,
Ralf

PS: If needed I'll explain this also in German 

[khfnet]

Hi Ralf,

1
I normaly never work with accu, only 220V. Accu use is sometimes for private things. Perhaps IMatch was not closed one time and  laptop goes to sleep. Thats all.

2
its a ThinkPad W530, i7, 8GB and 250 GB are free, that should work.
(DB1 600 files, DB2 3000 files)

3
If I need better hardware to use Imatch something is wrong.

[RalfC]

Hi Karl,

its a ThinkPad W530, i7, 8GB and 250 GB are free, that should work.
(DB1 600 files, DB2 3000 files)

3
If I need better hardware to use Imatch something is wrong.

I only tried to point out some harddisk related topics which can influence the loading of data from harddisk. Unfortunately, all those things make it difficult to compare the performance of different systems.

I had a quick look at the specs of the Lenovo W530: I don't think that the HW is not sufficient, just there is a bottleneck when loading the thumbnails.

Regards,
Ralf

Auch auf deutsch:
Mir ging es eigentlich nur darum aufzuzeigen, welche Faktoren die Leistung der Festplatte beeinflussen können (die alle außerhalb des Einflusses von IMatch sind). Die Faktoren machen es schwer die Performance zwischen verschiedenen System zu vergleichen.

Festplatten für Laptops werden normalerweise für geringe Energieaufnahme (auf Kosten der Geschwindigkeit) ausgelegt, damit der Laptop im Akku-Betrieb länger durchhält. Leider wird die Festplatte im Netz-Betrieb aber nicht schneller.

Wenn da ein paar Sachen ungünstig zusammen auftreten, kann es schon sein, dass IMatch am Anfang mit dem Laden der Thumbnails nicht hinterher kommt (z.B. weil noch andere Aktionen [von Windows oder Programmen] auf der Festplatte auszuführen sind) und dann beim Scrollen warten muss. IMatch muss zu der gleichen Zeit vermutlich auch noch andere Aktionen in der Datenbank ausführen, die dann auch mit Festplattenzugriffen einhergehen. Auch ein Virenscanner kann den Datentransfer bremsen, deshalb ist es gut für das Verzeichnis mit der Datenbank eine Scan-Ausnahme im Virenscanner zu definieren.

Mario hat das zu erklären versucht und auch die generellen Tipps (möglichst schnelle Harddisk, etc.) für einen optimierten Zugriff auf die Datenbank aufgeführt.

Viele Grüße,
Ralf

[khfnet]

Ich habe in einem anderen Post zum Thema Srollen die Daten zur Festplatte und nochmal ein logfile angefügt
Siehe hier:

https://www.photools.com/community/index.php?topic=3483.0