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

[Andy Robinson (blackadder-lists)]

Sebastian Klein wrote:
>Sent: 03 July 2009 10:08 PM
>To: josm-dev at openstreetmap.org
>Subject: [josm-dev] Image caching eats up all memory (since r1704)
>
>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.
>


I can't really comment on the current implementation of the photo viewer but
I did change to the AgPifoJ plugin because of the need to load many hundreds
of images into JOSM at the same time. It appears to manage memory much
better by not loading images into memory. The disadvantage of course is that
there can be a bit of latency, especially if the image files are on a slow
network server as mine are, however since running this way for the last
couple of years I've rarely had any JOSM memory problems, though I still use
a default 1024MB for JAVA when I run it.

Cheers

Andy