0.61: Hint for Database Feature needed

[Mike D]

I have been reading the forums for the last couple of days, the thumbnail issue seems often discussed. But displaying thumbs is done everywhere. So what? I noticed a thread yesterday where it was mentioned that someone recommended to use a dedicated SSD for the Databases to fight performace issues in conjuction with TC or something. I started using this somehow but somewhat no proper info out here how it works and what is does. Maybe you can help me with that. My setup is as follows: one W8-64 I use most of the time. Contains a SSD for System files, one HDD for istallations. Ivy Bridge Cpu, 8GB Ram. Media is found on an older Win7 machine, has a slot change Hdds. Connected with Esata, they always show up as network share on Win8. Both machines connected with gigabit ethernet. Browsing folders with lots of small files is not the best. Slow most at the times. The MP browser seems to create the db content once accessed, pulls the data from the network share and creates the db locally. Result is massive performance boost. I found out I had a Intel 320 Sdd left, spares from an old machine. I installed it on the W8 client, dedicated storing the databases to see what happens. After a few folders indexed it was great; no more cumbersome lags when going through folders. Like a local cache. When this indexing is going on about 20% Cpu Load and between 2 to 6 GB Ram used. But not only XnView NT Kernel and System were taking lots of that as well. After using it more it seemed lot like hit and miss; I got no pattern how this behaves. There must be cerain limits, for what is indexed, how much is indexed in one go how to keep the database in good state. Please let me how to archive this for stable everyday usage. I know this is beta and what I do is not the intended usage. But provide more in dept information about database usage. Looking forward to that.

[m.Th.]

Step 1: Break your message in paragraphs. It is much easier to read.

Step 2: Break your media in folders. It is much easier to read.

It it much more difficult to throw at once to the user many files for both Windows (read: NTFS subsystem has to do many I/O requests and pull out a big amount of data) and XnView (it must build / render many thumbnails which leads to many requests to DB -> cache stress -> in the case of cache miss again a bunch of I/O reads). Neither Windows neither XnView doesn't know that you want, in fact, from a gazillion of photos just a few.

Break your media in folders and if you won't find any other logic use dates / years. It is much better for everything. Something like this:

Wallpapers Galore
- 2013
----01
----02
-----...

Or in which way you like.

Of course, it is much more indicated to have a main logic for the folders and stick with that. It helps also for searching.

Weddings
- John and Jane
----Preparation
----Church
----Reception
----Meal & Party

Obviously, for big and dense archives the combination of both of above is the best (in Month folders put the logical names of the photo-reports or vice-versa).

In any case do not have more than, let's say, 700 photos in a folder. Ok, if you're a photo-reporter perhaps you'll be forced to have till 3k. Anyway, it hurts more a big number of files than big files but few in number.


Step 3: (You did it already) Distribute the I/O load.

Put the System on one drive, photos/media on another and DB on another. Depending on what you're doing, if you don't have enough drives, you can put DB with the OS together. Anyway, you must know that DB will be used a lot in many and small requests whereas the media drive in big and rather sparse requests (excluding of course the Thumbnail creation phase which you can do overnight if you're really at the cutting edge with the performance).

Step 4: Grow the DB memory in XnView's Tools | Settings

Go to Tools | Settings | Database and put a bigger value for 'Memory usage for Database engine' - let's say 100-200 MB depending on what you do and how many GB RAM you have.

just my2c & HTH,