[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