I have JOSM installed on Linux via Flatpak. I’m trying to figure out how to increase the allocated RAM to 2 GB. It launches as follows:
flatpak run --branch=stable --arch=x86_64 --command=josm --file-forwarding org.openstreetmap.josm @@u %U @@
As you can see, there’s no ‘java’ here. I look into the JOSM folder in /var/lib/flatpak/app/org.openstreetmap.josm/, and find ./x86_64/stable/active/files/bin/josm. In this script… there’s a lot going on. I don’t see a good place to add the -Xmx2G option. Anyone know?
Any arguments passed to flatpak-run are passed to the java script in the flatpak but that in turn passes them to JOSM rather than to Java so that doesn’t help.
What does work is using JAVA_OPTS to pass options that are then given to java, which can either be done in the environment:
JAVA_OPTS=-Xmx2G flatpak run org.openstreetmap.josm
or with an argument to flatpak-run:
flatpak run --env=JAVA_OPTS=-Xmx2G org.openstreetmap.josm
Note that if your machine has more than 8Gb of RAM then it will default to options of -XX:MaxRAMPercentage=75.0 -Xms256m which allows up to 75% of RAM to be used so this should only really be needed for machines with less than 8Gb of memory.
Of specific note for this conversation, L63should be setting the maximum ram to 75% of the system RAM if you have 8G or more of RAM (as @TomH said).
If you really are limited to <2G of RAM, you have something else going on. How much RAM does your system have? I’m thinking 4G or less. Or you have manually set JAVA_OPTS somewhere else (try running env | grep JAVA_OPT to see if you’ve done this).
I didn’t actually check how much RAM that JOSM was using (I have 32 GB). I used Overpass to download the entire city of Chicago and even in wireframe mode with most elements disabled/hidden, performance was poor, and I read that JOSM was limited to some small amount like 256M or 512M, so I thought that limit was to blame. Seems that was incorrect / outdated.
There is an experimental rendering method (Tiled Rendering) that you can enable instead of wireframe mode. It reduces the UI lag at low zoom levels with lots of data.
Rendering is a bit slower (it does 25x the tile size to get positioning mostly right), and there are some inconsistent off-by-one or two pixel errors. You don’t really have to worry about that though, since it transitions to the traditional rendering method at high zoom levels (AKA the levels where you actually care about precision). It does not, however, render everything in view every frame. The big thing is that it doesn’t block the UI thread.
I also don’t know when you last updated the JOSM flatpak, but r19166 had a significant performance improvement for wireframe rendering on large datasets.