GRASS GIS Performance

GRASS GIS Performance

GRASS GIS is noted for being ready for massive data analysis. This page contains an yet incomplete collection of performance indicators.

Architecture

GRASS GIS is fully 32bit and 64bit compliant. See also the Software requirements specification.

Number of opened input files

There are only operating system constraints of the number of input files which can be opened simultaneously. Commonly the limit is 1024 files. In operating systems like Linux this limit can be overcome with the "ulimit" settings.

See also

• r.series
• r.series.accumulate

Memory management

Due to the modular architecture of GRASS GIS the overhead of the software itself is minimal.

Raster data operations: where appropriate, modules offer a parameter to optimize caching ("memory" parameter).

1. Pixel based operations: they have very low impact on memory usage.
2. Moving window based operations: they have medium impact on memory usage.
3. Full map operations (watersheds, cost surfaces, etc.): they have high impact on memory usage.
4. Statistical operations: while univariate statistics have low impact on memory usage, quartiles and other aggregated statistics have medium impact on memory usage.

Vector data operations:

1. Vector point operations: memory consumption depends on the amount of points. LiDAR data processing is commonly demanding. For some operations the creation of topology can be skipped to reduce the memory footprint.
2. Vector line operations: hey have low impact on memory usage.
3. Vector area/faces operations: they have high impact on memory usage.
4. Topological versus non-topological operations: a subset of vector modules is able to operate on point vector maps without topology which saves notably RAM usage.

Database operations:

• Most operations are simply SQL transactions with low impact on memory usage.

See also

• Solving Memory issues when dealing with large amounts of data

Vector management

Vector geometry

In all GRASS GIS versions,

• with topology the feature limit is at time 2^31 - 1 (about 2 billion) features per vector map.
• TODO: add limit if topology creation is disabled at import for points (e.g., LiDAR points).

Maximum Number of Attribute Columns

The maximum number of attribute columns of a table connected to a vector map is defined by the capabilities of the the selected database backend (set with db.connect).

• DBF-Backend: GRASS 4.x - 6.x use by default the DBF backend. While there is no explicitly stated maximum number of allowed attribute columns, Web sources report a maximum between 128 and 1023/24. Trials with GRASS 6.4.2 in 2012 result in write failure if > 2000 attribute columns are used. Export to DBF-based ESRI Shapefile provides a warning if more that 255 attributes are used: Other software tools may ignore all further attributes, hence a maximum of 128 columns may be prudent.
• SQLite-Backend: GRASS 7.x uses by default the SQLite backend. The default maximum number of attribute columns is 2000 according to the specifications. This number can be increased by compiling SQlite with changed settings.
• MySQL-Backend: The default maximum number of attribute columns is 4096 according to the specifications.
• PostgreSQL-Backend: The default maximum number of attribute columns is 250-1600 according to the specifications depending on column types.
• Oracle-Backend: The default maximum number of attribute columns is 1000 according to the specifications.

Maximum file size of the attributes file

• DBF-Backend (in GRASS 6 the default DB backend): to be added (2Gb? in case of LFS enabled?)
• SQLite-Backend (in GRASS 7 the default DB backend): The maximum file size of a SQLite db is 140 TB, independent of the architecture, i.e. Large File Support (LFS) is always there. Usually SQLite will hit the maximum file size limit of the underlying filesystem or disk hardware size limit long before it hits its own internal size limit.

Large file support

Large raster data processing

GRASS GIS 7 supports the off_t type, hence it can address an enormous amount of raster data.

See also

• Large raster data processing

Some benchmarks

• Import of ECAD 6.0 Tmean dataset: 22650 layers in single netCDF file: import takes 300 Seconds while reading file via NFS (i.e. 75 maps per second)
• Calculation of watersheds, half basins, flow accumulation, drainage directions, and stream with r.watershed for an area of 90,000 rows x 100,000 cols (9,000,000,000 cells, metric) successfully done in 77.2 hours (Intel Xeon X5670, 2.93GHz)
• European DEM at 25m (eudem_dem_3035_europe.tif, 24.1 GB GeoTIFF, 48 billion cells) processing:
  • Import of this GeoTIFF file with r.in.gdal on a blade via NFS: a) 77h without memory option (hence 40MB = GDAL's default cache), b) '1.5h' with memory=300 (hence using 300MB GDAL cache), c) '1.5h' with memory=2000 (hence using 2GB GDAL cache)
• ... add more

Large vector data processing

GRASS GIS 7 supports the off_t type, hence it can address an enormous amount of vector data. Currently multi-billion vector points have been managed (citation) without topology (since not needed). In all GRASS versions, the limit with topology is at time 2^31 - 1 (about 2 billion) features per vector map.

Some benchmarks

• ...
• ... add more

Parallelization

In GRASS 7, a few modules have been parallelized with openMP. However, if data can be processed in chunks, GRASS GIS can be used on clusters.

• OpenMP/Benchmarks

User reports

• Case studies

See also

• Parallel GRASS jobs
• Software requirements specification
• Performance issues GRASS vs. ArcGIS
• GIS workstation setup tips (OSGeo Wiki page)