Performance Tuning

7.8 Performance Tuning

If you are running into issues with memory consumption or slow response of the IDV, there are several things you can do.

The amount of memory used by the IDV will depend on the size of the datasets you use and the types of displays. Datasets rendered as 2D depictions (plan views - contours or color shaded displays) use much less memory than 3D displays (isosurfaces, cross sections). Large datasets (images, dense grids) will use much more memory.

There are several features in the IDV that allow you to more efficiently view large datasets:

7.8.0	Temporal/Spatial Subset of Data Subsetting the data before display reduces the memory and display time
7.8.1	Memory allocation Change the amount of memory allocated to the IDV
7.8.2	Data Caching Data caching uses more memory
7.8.3	Caching to disk Data source field caching
7.8.4	Maximum grid/image size Reducing the maximum size of a display can reduce the memory used
7.8.5	Fast Rendering Fast rendering reduces memory and time at the expense of accuracy
7.8.6	Parallel Rendering and Data Reading Parallel Rendering and Data Reading

7.8.0 Temporal/Spatial Subset of Data

Some data sources allow you to subset the data temporally and spatially. You can set these properties for all fields in a dataset through the menu of the data source (double click on the Data Source in the Field Selector) or you can set these for individual field using the tabs in the lower right corner of the Field Selector. For more information, see the Data Source Properties section of the IDV User's Guide.

7.8.1 Memory allocation

By default, the IDV startup script (runIDV) allocates 512 megabytes of maximum memory for Java. This is usually the optimum amount for a Windows system with 1 gigabyte of physical memory (RAM). Windows takes up half of that anyway and once Windows has to start swapping, performance severely degrades. On a Linux system, you can probably get away with 700m for 1 Gb of memory as it does a much better job of swapping. All this also depends on what else you are running on the machine and how much memory those applications use.

If your system has more than 1 Gb of memory, increasing the amount available to the IDV can improve performance for displaying large datasets. You can change the runIDV script to increase the amount of memory. In that script, change the -Xmx512m to some higher number (e.g. -Xmx1024m). The number is the number of bytes, the trailing m is a multiplier (m=mega). Do not use the maximum amount of memory on your machine as some is needed for the operating system itself. If the system has to use swap memory, performance will degrade as well. For a system with 2 Gb of physical memory, you can probably allocate 1.5 Gb to the IDV. If you have less than 1 Gb of RAM, you should start the IDV with about 1/2 of the total memory (e.g., if your system has only 512 megabytes of RAM, you should use -Xmx256m).

7.8.2 Data Caching

By default, the IDV caches the data used for a display in memory. If a field is used more than once for several displays, caching the data prevents an additional reading from of the data from disk or a remote server. If you are only displaying/using a field (i.e. not using it for multiple displays or calculations), you can keep the IDV from caching it in memory. You can turn off data caching by unchecking the Cache data in memory checkbox on the Data & Formats tab of the user preferences (accessible from the menu).

7.8.3 Caching to disk

For grids and images you can specify that the data for each time step is cached to disk. From the data source properties dialog select "Always cache to disk". Using this there will be some processing overhead because the IDV, after reading a grid or image timestep, will write the data to disk. However, the advantage is that only one time step's worth of data will be held in memory at a time. The "Delay" field allows you to specify a delay before the data is removed from memory. For example, if you are doing an interactive data probe then every time you move the probe the IDV needs to access the data in memory. If there was no delay then the IDV would have to read the data from disk at every probe movement.

7.8.4 Maximum grid/image size

You can also set the maximum size of a grid or image that will be displayed. This will allow you to download a large image or grid, but it will be re-sampled before displaying if it is larger than the maximum size you have asked for. You can set the maximum image/grid size under the Data & Formats tab of the user preferences (accessible from the menu).

7.8.5 Fast Rendering

By default, the IDV will NOT try to adjust the data renderings to account for projection seams. This is computationally intensive in some cases and slows down the display of data. When the preference "Use Fast Rendering" (under the General tab of the user preferences ( menu)) is set, the IDV will not try to account for the projection seams. If you are displaying data in its native projection, this will result in faster rendering of the data depiction. However, if you have several displays of data, each from a different data source and on a different projection, you may see anomalies in the displays (spurious lines, portions of images). At that point, you can turn off fast rendering for a particular display using the menu of the Display Control for that display, or set your system preference back to not use fast rendering.

7.8.6 Parallel Rendering and Data Reading

If you are running the IDV on a multi-core machine you can configure the IDV to render individual time steps in parallel. You can also do remote data reads in parallel. This typically results in a 50% reduction in overall data reading and rendering time.

There are 2 preferences in the Preferences->Data & Format tab. One is the number of threads used for rendering. This defaults to the number of processors on your machine. The second is the number of threads used for data reading. This defaults to 4.

For rendering the IDV will render each time step in parallel. Note: since the rendering processes can allocate temporary memory it is possible to exhaust the available memory if too many threads are running concurrently. While we do not get linear speedup with the number of cores available for rendering (probably due to memory contention issues) we do see 40%-50% performance improvements for complex rendering tasks (e.g., contouring).

The second preference is used when reading individual time steps of data from remote ADDE and OpenDAP servers. This parallelization takes advantage of the multiple cores available on the remote server and somewhat the available bandwidth on the network. We do see a linear speed up in accessing remote data based on the number of cores on the remote server (ADDE or OpenDAP). However, we've seen that if you load the server too much your performance is degraded, probably due to file system issues.

Unidata's Integrated Data Viewer > Miscellaneous