Markus Metz wrote: > The segment lib implementation in trunk is considerably faster than in > 6.x, but not as efficient as the caching method of r.proj. Some > reasons why the segment library is slower than the caching code in > r.proj are 1) write support in the segment lib, 2) flexible data > storage size in the segment lib, 3) flexible tile size in the segment > lib, 4) bad abuse of the segment library, e.g. in r.los.
The main factors for performance are whether the tile size is fixed at compile time and whether it's known (at compile time) to be a power of two. It wouldn't be particularly hard to structure the r.proj tile cache code such that the tile size can be set by the module, so long as it's set at compile time. Allowing the tile size to be set at run time incurs an inevitable performance penalty. The power-of-two constraint needn't be enforced by the code. The shifts and masks could be replaced by multiplication, division and modulo; any modern compiler will optimise these back to shifts and masks if the tile size is a compile-time constant which is a power of two. OTOH, I'm not sure there's any benefit to relaxing the requirement. Some modules may be less efficient if the tile size is significantly too small or too large, but being off by a factor of sqrt(2) shouldn't be an issue. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev