[GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0,6.2 raster commands

[Roy Sanderson]

Hello Again

Thanks for the various piecies of feedback - I've tried removing the null
file (and there isn't a MASK), and unfortunately it hasn't made much
difference.

Having done some very rough benchmarking, based on a simple r.stats command
on a much smaller map than our user was struggling with, figures are:

Grass 4.3 - 10 seconds
Grass 5.4 - 67 seconds
Grass 6.2 - 74 seconds

Given that this is being run across an NFS network, the figures are only
approximate, but it looks as though the performance hit came from the
switch from Grass 4.3 to 5.4.  Oddly enough, even the d.rast commands seem
faster in Grass 4 (though that may simply be because the no. of colours
used in the monitor is lower).

Best wishes
Roy

At 06:10 01/05/07 +0100, Glynn Clements wrote:
>
>Helena Mitasova wrote:
>
>> does the null implementation affect also the runs with rasters that  
>> have no nulls and there is no MASK present?
>
>It affects any raster which has a null bitmap, even if no cells are
>actually null.
>
>> 10x faster is a huge difference - it may be worthwhile to find out
>> whether it is true for integer maps without nulls and whether it
>> is really nulls slowing it down so badly.
>
>It's relatively easy to test the effect of the null bitmap:
>delete/rename the cell_misc/<name>/null file. There will still be some
>residual overhead due to the conversion of zeroes to nulls, but this
>will determine the cost of the filesystem calls.
>
>> There were many discussions about the null implementation and as  
>> Glynn correctly
>> points out the main driver for the current design was to sacrifice  
>> the performance
>> to preserve the backwards compatibility. Wishes of old users (many of  
>> whom
>> contributed funds to GRASS development) were given very high priority.
>
>It's possible to embed nulls while retaining compatibility, but the
>result is that most CELL maps will end up using 4 bytes per cell
>(prior to RLE or zlib compression).
>
>-- 
>Glynn Clements <glynn at gclements.plus.com>
>
>