Larry Becker's JUMP Performance Tips

The following information was posted by Larry Becker to the JPP Developer's Mailing list and has been posted here by the Sunburned Surveyor for easy reference.

In the process of doing some software optimizations to the JUMP framework recently, I have learned a few things that can be done by users to increase the speed of JUMP operations, or at least avoid significant slow downs. In order of importance, they are:

1. Ensure that you have sufficient free memory by using JUMP's Help->About dialog. When Committed Memory approaches Total Memory, the JVM (Java Virtual Machine) is forced to do constant garbage collection which slows down operations that use lots of temporary memory like redrawing the screen. Unfortunately there is no certain rule for how much is enough, but I would allow at least 10% free. The different versions of JUMP use different methods of allocating memory limits. The SkyJUMP memory limit can be set by increasing the number in the -Xmx512m parameter in the SkyJUMP.ini file in the Jump/bin directory. As a general rule, never increase the number above the amount of physical memory your machine actually has.
2. This one is also related to memory usage. If you are doing tasks which involve loading and removing large layers, you will notice that JUMP will not free the memory used by removed layers. The only way to free the memory is to close the task (project). Watch the Committed Memory status and when it approaches the limit, you should consider closing the task and reloading it. Note to developers: unfortunately there doesn't seem to be an easy fix for this as many classes in JUMP hoard local copies of the context which may prevent garbage collection of removed layers (this is speculation on my part).
3. Avoid using the labels style on very large layers. Although decimation optimization can reduce redraw times for layers with a large extent, it currently has no effect on text labels. Enabling text labeling on large layers (like burlulc) can cause JUMP to spend minutes rendering tiny invisible text labels. Of course, thanks to JUMP's threaded rendering architecture, you won't be aware that this extra processing is going on, but it will still slow down other processing being done on your computer.
4. Consider using the Change Styles Scale tab to avoid displaying a layer at an inappropriate scale. Usually this involves not showing small objects when the zoom level is near the full extent of the layer. Depending on the density of your data, this could be an option for point, label only (scaled), and small feature layers.
5. Consider turning off line rendering in the style dialog for polygon layers that don't require borders (such as water layers). It takes just as long for JUMP to render the polygon border as it does the fill, so it can cut the redraw time in half.
6. When working with tasks (projects) that have a very large number of layers, and many of the layers are often invisible, consider breaking the task into parts and using the SkyJUMP Merge Task/Archive command to load them into the current task again on an as needed basis. I'm not sure if any of the other JUMP versions have a similar capability, or if OpenJump is going to adopt this feature. The advantage of Merge vs Load Dataset is that layers maintain their style information.
7. Another tip to prevent running out of memory when working with a very large number of layers is to make the map window as small as possible. JUMP creates an off screen bitmap the size of the map panel for each visible layer. Imagine opening a hundred picture files at one time and you can see where all the memory goes!