Check memory usage to track problems (Image Caching & co

[Olivier_G]

I just saw a whopping 200MB memory usage for XnView after a bit of browsing and checking 18MB (6MP) photos - no single photo opened at that time -> something was really going wrong. I decided to track memory usage to find where it could come from.
Beware: long boring real-time posting...

A. without cache (Options>View>File List>Cache: both unchecked)
-> start in an empty folder: 6.220KB
quite good
-> go/start in a folder with 747 photos (thumbnails:179x179): 62.152KB
I suppose XnView loads all thumbnails of the folder in memory -> I'll have troubles with folders of 5.000 and more. A random access to the Thumbnails actually shown would be much more efficient (+faster when you enter a large folder, +less memory used, -sligthly slower while browsing).
-> switch to another large folder (369 photos): 30.544KB
OK: memory from previous folders is released.
-> back to first folder (747 photos): 62.332KB
-> selecting a photo without preview enabled: no change
OK. But pre-caching the image at this stage could be useful (+stopped if the user switch to another task +continued if the user open the image before the end)
-> selecting a photo with preview: 80.732KB
OK. The whole image is loaded in memory for preview. Shouldn't be reloaded for opening
-> opening photo for viewing (Full Screen): 84.128KB
I don't know what those 4MB are for, but there is another window "PFull" running": it seems that the "full screen" is actually another application launched...
-> going back to browser (double click->image closed): 80.736KB
This "Full Screen add-on" has been closed
-> opening photo (normal viewing): 102.564KB
OK: the image is opened additionaly to independantly manage windows. Checked by choosing another image in browser -> same memory
-> opening another photo (normal viewing): 124.408KB OK, closing image: 102.552KB OK
-> I check by opening several images (normal/full screen) and close all images, back to browser alone: 80.736KB OK
-> Switching Preview off: 80.736KB OK: image is still cached
-> Selecting another image: 62.284KB Cache has been released. I believe it should be kept, as explained before
-> Back to empty folder: 7.632KB

=> Without Cache: no bug detected. I believe that a selective random access to Thumbnails actually shown +precaching selected image (even without preview) would be better. I need to test/check that no additional reading from the disk is made while switching from preview to view.

To be followed soon... hopefully

[Olivier_G]

B. with cache (ahead+current)
-> start Browser in empty folder: 6.220KB; in folder with 747 photos: 62.044KB
-> View an image Full Screen: 102.460KB OK: Current and Next images are loaded
-> Move to previous image: 120.852KB Problem1! Current and ex-Current should be loaded, but ex-Next should also be released
-> Move to previous image: 139.292KB Problem1 confirmed!
-> Return to browser (no image opened): 139.072KB No memory is released.

I tried going back through several images in Full Screen and stopped at 400MB being used by XnView alone...
Selecting another image in Browser and viewing it Full Screen release all images previously loaded...
...except if you have opened in between an image in the normal Viewer. Then, the only way to release memory seems to switch to another folder.

=> One Bug found! In Full Screen (lite?) the "Next image" cached is not released when moving to previous image.

More testings to come later...

Olivier

[Olivier_G]

Still B. with cache (ahead+current)

-> Start Browser in folder with 747 photos: 62.060KB
-> View an image Full Screen: 100.944KB Current+Next loaded
-> Move to next image: 119.356KB ex-current and current are kept, next is loaded
-> Move to next image: 119.356KB, but XnView peaked shortly at 137.820KB... something else has been loaded?
-> Back to Browser (image closed): 119.084KB
-> Selecting another image: 100.620KB only one image (previous/current/next) is released
-> Opening this image (Full Screen): 137.800KB Problem2!The ex-current&next haven't been released, but the new ones are loaded
-> Moving to next image: 119.352KB Situation seems to be corrected

However, by switching back and forth between Browser and Full Screen, each time selecting a different image (and not cached), the memory keeps increasing. I stopped at 400MB. If you select an image just after the previous one (therefore: cached[?]), the memory is released.

There are some issues with the way the cache is managed: maybe unnecessary RAM use due to a wrong sequence, memory is not correctly released... which leads to problem2.

I will make the same tests in normal Viewer, and check exactly what happens (disk access, memory, CPU usage, timings) when caching is done.

Olivier

[marsh]

Olivier_G, while testing remember that unless the option view>'one view opened' is checked, the viewer can open and keep open a multitude of images. You can check the menu>window>??? to see a listing these files.

[Olivier_G]

Marsh, thanks for the feedback.
- I have View>one view unchecked
- but Browser<>Full Screen(lite) actually close the image when going back

I re-checked the number of windows opened while getting problem1 and problem2, as you indicated: the only window open/listed is the browser and I still had 400MB+ used by XnView.

It is quite easy to check/reproduce (check memory before):
- Problem1: Browser>Full Screen(lite), move several images back, Full Screen>Browser
- Problem2: Browser>Full Screen(lite), Full Screen>Browser, and repeat on every other image of your folder
=> check your memory after doing this on 10 large images (digital photography)

Olivier

[Olivier_G]

With Cache, in normal Viewer

I made the same testings as described above, and didn't get Problem1 and Problem2, nor any bug...
The cache is properly released (when moving and when closing a window).

The only issue I found is that the cache (previous, current, next) is actually kept with each opened image/window -> it uses a lot of memory when you open several images (and there is little chance that you will actually move within those opened windows).

Olivier

[Olivier_G]

Effectiveness of XnView's Cache?

I couldn't find any issue with CPU nor Disk access (minor ones: why check the programs of 'Open with' list for each selection/move, when this list is fixed? The 'next' image is cached before the current one is actually shown: is it more efficient?).

However, I think that there are some more Cache issues that impact its effectiveness:
- Opening a 60MB TIFF not in cache=0.8s [time to full display]
- Opening a 60MB TIFF in cache (moving from previous one +cache enabled)=0.7s

In comparison with ACDSee: Opening without cache=0.5s and Opening with cache=near instant.

=> My feeling right now is that XnView's Caching management is broken, and that the bugs outweight by far its advantages. I would recommend to disable it for the time being...

It should be possible to improve it quite a lot, by redesigning the way it works (more to come...) and correcting bugs.

Olivier

[Olivier_G]

After finding two major bugs, some issues and almost no advantage in the current implementation of the caching system, I would like to propose and discuss a better way to handle the caching of images in RAM.

Some general ideas:
- the goal is to display the wanted image as fast as possible (ie: caching is secondary to actually displaying the current image).
- RAM should be used only when necessary (ie: balance with probability*advantage). Peaks should be avoided and memory released as soon as possible.
- Minimize Disk and CPU use (ie: avoid to release/reload again, etc...)

I'll try first to find some common behaviours:
- If only one image is selected in the browser, it has a 'good' probability to be opened (especially without Preview enabled). If the selection changes, the probability gets back to low.
- When the user opens a Viewer window, the probability to navigate (Next>Previous) with it is 'good' (and 'low' for all other opened Viewer windows). If the user actually starts to navigate with a Viewer window, probability gets to 'high' for this particular window (and low for all others).
- When navigating with the Viewer, the probability is higher for 'Next' than for 'Previous'. However, when the user has actually started to navigate, the probability gets higher for the selected direction (but going back also have a strong probability).


So how does it work?

A reminder that in all situations, the priority should be:
1. to give control to the user (and cancel any working process if not needed anymore)*
2. to show the result of the action (ie: open image/preview, show data, etc...)
3. to cache what is needed (and only when it won't slow down [1] or [2]*)

A. No Cache
Easy one: no cache at all should be used.
Memory for the image should also be released right after closing Full Screen lite* or closing the Viewer window.
I even think that the memory of the full image should be released just after being used for the Preview area*.


B. With Cache
So the problem is to correctly manage the loading(from disk) and unloading(from memory) of images, based on the behaviours explained before. Because there can be several sources of caching (ie: Browser window, each Viewer window, Full Screen lite...) sharing the same memory and files, it should be managed as the union of several individual cache lists:
-> If an image to be loaded is not in any of those lists, it will be read from disk and added to the cache list of the corresponding source.
-> If an image to be loaded is already in any of those lists, it means that it is already in memory and doesn't need to be read from disk. It will however be added to the cache list of the source (without doubles).
-> An image to be removed from the cache of one source will first be removed from its own list. If the image is not listed anymore in any cache list, it will then be unloaded from memory.

Let's go:
Browser
- If a single image is selected in the Browser, it should be cached (with Preview, but even without Preview*). If its focus changes, this previous cache should immediately be removed.
- For a multi-selection without Preview: no caching
- For a multi-selection with Preview: keep in cache only the image in focus (which has been loaded for previewing).
Viewer windows
- When an image is opened: add the current, next and previous images in cache of this window. Remove all caches of other Viewer windows* (except their current ones).
- When the Viewer window in focus is used to navigate through images: add the current, next and previous images in cache of this window and update it accordingly. Remove all caches of other Viewer windows* (except their current ones).
- When a Viewer window is closed: remove all its cache list.
Full Screen Lite
- When Full Screen lite is opened: add the current, next and previous images in cache of this window. Remove all caches of other Viewer windows* (except their current ones).
- When Full Screen lite is closed: remove all its cache list*.

After each of those actions, the memory cache should be updated accordingly to the the cache lists, as described before.


So... what do you think about all this ?


Olivier
PS: "*" means that it is not currently done this way in XnView

[marsh]

Beware: long boring real-time posting...

Confirmed problem:
1. [X] 'Keep Current Image in Cache'
2. With browser fullscreen, look at many images using <page down>
3. Memory usage goes up and does not go down again (this does not occur in viewer fullscreen).

[Olivier_G]

Marsh: thank you for testing this as well.

You actually just found a new bug!
I didn't described this one (I had: 'going up' and 'choosing every other file' in fs lite) because it doesn't happen if you additionally check "read one image ahead"... and I limited myself to 'no cache' and 'both cache enabled'.

Olivier

[marsh]

It is probably a good idea to leave cache off until next release.
Another image cache problem is acknowledged here:
http://newsgroup.xnview.com/viewtopic.php?t=2883

[Olivier_G]

Fixed in 1.80.2 ...and that is great news!!!

Thank you Pierre!
- The 3 important bugs have all been fixed
- I re-tested the performance: 0.8s without cache, 0.4s with cache => Caching works as expected (and there is probably a solution to get instant display)
=> We are back to business with this Cache System (grade=A... ).

There are still some (minor) suggestions left, but I will start a new 'suggestion thread' for those.

Thanks,

Olivier