[GRASS-dev] I've tripled GRASS's I/O speed

[Vaclav Petras]

On Fri, Oct 2, 2015 at 7:12 PM, Seth Price <seth at planet.com> wrote:

> I imagine the best test will need pretty low level access to the cellhd
> structure to look at the compression flags. Is that what you mean? Or would
> a better way include looking at the output of `r.compress`?
>

Yes, best would be to test the individual functions on the lowest level
(lib/raster3d and raster3d/r3.flow). However, this is hard to do (you need
to write a C program* and implement all tests yourself). I suggest to start
with high level tests; this is much easier (you need to write a script
ideally using existing Python packages).

Comparing r.univar output for a raster map before and after r.compress
execution sounds like a good start. For the testing framework, the right
approach is to copy and existing map to the current Mapset, run r.univar to
get the output, run r.compress, run r.univar again and diff the results.
This can be done in Bash or Python; Bash looks simpler at the beginning,
but existing functionally in Python (esp. the gunittest package) will make
things easier at the end.

Vaclav


Some gunittest references:
https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#tests-of-grass-modules
https://grass.osgeo.org/grass71/manuals/libpython/gunittest.html#gunittest.case.TestCase.runModule
https://grass.osgeo.org/grass71/manuals/libpython/gunittest.html#gunittest.case.TestCase.assertModuleKeyValue

* Parts of library which are available through ctypes can be also tested
relatively easily in Python without a need to write a wrapper C program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151003/584f441c/attachment.html>