blazek at itc.it
Wed Apr 23 05:55:38 EDT 2003
On Tuesday 22 April 2003 05:48 pm, Glynn Clements wrote:
> Actually, that's not entirely a joke. There is a legitimate argument
> for sacrificing performance in favour of other properties. In this
> case, simplicity. You can almost always get performance improvements
> by replacing generic functions with multiple specific-case versions,
> but doing so creates maintainence problems, and maintenance is GRASS'
> biggest problem.
Can I conclude?: GRASS needs RGB CT but we (you) don't feel to have
enough human sources for GRASS maintenance and prefer not to increase
complexity for now.
So back to
> Given that the speed difference between d.rgb and d.photo appears to
> be almost entirely due to the additional time spent reading three maps
> instead of one, it would definitely be worth looking into whether the
> reading speed can be improved. If it could, that would benefit
stat = embed_nulls_nomask(fd, (void *) cell, row, CELL_TYPE, 0);
in G_get_c_raster_row_nomask() and time fall down to 1.469s from
original 6.930s. So all evil comes from NULLs.
and G_get_null_value_row_nomask() spends most of the time
(2.161s if commented)
It means that G_get_null_value_row() takes more than 230%
of the time required for G_get_c_raster_row() (if NULLs not read).
It must be possible to improve performance of G_get_null_value_row()
but rasters are not my hobby.
BTW: It seems that raster values are masked by NULLs in current region
resolution instead of original raster map resolution. I am not sure if it is good.
That is probably more general problem of conversion of rasters to current region.
More information about the grass-dev