[josm-dev] Image caching eats up all memory (since r1704)

Sebastian Klein bastikln at googlemail.com
Fri Jul 3 22:07:34 BST 2009


Hi,

about a week ago jttt cleaned up the code for the photo viewer.
I like the patch: The structure is much better now, it does not take 
ages to load the images and some apparent bugs are gone. There is one 
thing I'd like to discuss though.

  - After starting up and loading a gpx track josm uses approx. 51 MB of 
memory on my system. (nothing wrong so far)

  - After loading 16 images (43 MB in total) the memory usage shoots up 
to 509 MB(!).

  - Having started with "java -Xmx500m" option it won't use more than 
522 MB of memory no matter what I do afterwards (loading more images, 
download osm-data, etc.). Note that the caching is done using weak 
references so the memory is freed if needed by other parts of the app.

As far as I can say, this is not a bug, but supposed to be a feature.

Pro:
  - When clicking a thumbnail or pressing 'next' the image is loaded 
very fast (if still in cache).

Con:
  - If you have >= 2 GB of memory there might be none.
But some people have not. (like me)
(I have to grant josm a fair amount of memory via -Xmx...m (just in 
case) - got surprised by the "funny things may happen" dialog too often.)
So using josm and, say, a browser, there is not much memory left for the 
os and other apps.
                              ___________

Now my humble opinion on how it could be improved:

  - If the user clicks a thumbnail, load the image from disk, resize and 
display.
  - Then fetch the next and previous image in background while he/she is 
enjoying the current photograph.
  - repeat
Otherwise no caching.

(One could also have a disk cache (like gnome/nautilus thumbnail cache), 
but that might be a little too ambitious.)


Sebastian


PS:
I'm quite new to josm (and osm in general), so I have a lot of ideas for 
improvements and changes. I'll save that for later though.




More information about the josm-dev mailing list