Previous:  Image Movie Format Next: Java Developer Topics Table of contents Frames User guide
Unidata IDV Workshop for version 6.2u2 > Advanced Topics > Miscellaneous Items

4.5.4 Performance Tuning
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:  Temporal/Spatial Subset of Data
Subsetting the data before display reduces the memory and display time  Memory allocation
Change the amount of memory allocated to the IDV  Data Caching
Data caching uses more memory  Caching to disk
Data source field caching  Maximum grid/image size
Reducing the maximum size of a display can reduce the memory used  Fast Rendering
Fast rendering reduces memory and time at the expense of accuracy  Parallel Rendering and Data Reading
Parallel Rendering and Data Reading 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 Properties 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. Memory allocation
By default, the IDV startup script (runIDV (Unix) or runIDV.bat (Windows)) tunes the amount of memory allocated to the IDV according to system parameters. On 64 bit computers, the memory allocation amount is 80% of the available RAM. On 32 bit computers, the amount is the minimum of 1.5GB and the available RAM minus 512MB.

In addition, users can change the memory settings in the Edit→Preferences, System tab. In order for these changes to take effect, the user will have to restart the IDV.

In rare circumstances, the IDV start script cannot determine the optimal amount of memory for the IDV. In this unusual case, the IDV start script allocates 512MB. The user can still go to the Edit→Preferences, System tab and adjust memory settings. Again, the user must restart the IDV in order for this to take effect.

In other exceptional situations, the user may still wish to override the automatic tuning mechanism. In the body of the runIDV script, there are instructions on how to achieve this change, although this should rarely be necessary. 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 System tab of the user preferences (accessible from the Edit→Preferences menu). Caching to disk
The IDV has a caching facility where actively used data (e.g., gridded fields, satellite image, radar) is held in a memory cache. As the amount of data increases the IDV will write the data out to a temporary space on your local disk. If that data is needed again (e.g., rerendering the display) then the IDV will need to go to disk and re-read the data. This may cause some delays.

The memory cache size is intially set at 30% of your maximum memory. This can be changed in the Edit→Preferences, System tab.

In a worst case scenario you could have a very long animation loop of imagery. In this case every time one of the images is displayed while animating its data needs to be accessed. If you have very large images or a very long loop then the images needed to display will be on disk and the time it takes to read them from disk for display will be quite noticable. In this case you can reduce the resolution of the images, reduce the number of times being displayed or increase the cache and/or overall memory size. 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 System tab of the user preferences (accessible from the Edit→Preferences menu). 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 (Edit→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 Edit→Properties menu of the Display Control for that display, or set your system preference back to not use fast rendering. 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 Edit→Preferences, System 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.


Previous:  Image Movie Format Next: Java Developer Topics Table of contents Frames User guide
Unidata IDV Workshop for version 6.2u2 > Advanced Topics > Miscellaneous Items