GRASS GIS Performance: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
No edit summary
(+benchmark: 22650 layers in a netCDF file)
Line 28: Line 28:
See also
See also
* [[Large raster data processing]]
* [[Large raster data processing]]
Some benchmarks:
* Import of [http://www.ecad.eu/ ECAD 6.0] Tmean dataset: 22650 layers in single netCDF file: 300 Seconds while reading file via NFS


=== Large vector data processing ===
=== Large vector data processing ===

Revision as of 11:57, 17 August 2012

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.

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

Memory management

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

See also

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

Some benchmarks:

  • Import of ECAD 6.0 Tmean dataset: 22650 layers in single netCDF file: 300 Seconds while reading file via NFS

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.

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.

See also: