[GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[GRASS GIS]

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed
--------------------------+---------------------------
  Reporter:  sprice       |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.1.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  ZLIB LZ4 ZSTD
       CPU:  OSX/Intel    |   Platform:  MacOSX
--------------------------+---------------------------

Comment (by wenzeslaus):

 Replying to [comment:8 sprice]:
 > I think I've fixed all issues.

 It works for me as well. With `GRASS_INT_LZ4=1` I get

 {{{
 Executed 129 test files in 0:25:10.484136.
 From them 120 files (93%) were successful and 9 files (7%) failed.
 }}}

 without `GRASS_INT_LZ4` it is the same including the time (I don't expect
 that the improvement should be visible on speed of the tests, at least not
 much). (7% is little bit more than
 [http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-10-09-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html
 on the server] but the one test which is different is unrelated to this.)
 Now running tests also with the other compressions.

 > And a bad memory read that was in there before that valgrind discovered.
 And a segfault in n_les_assemble.c (via r.gwflow) that someone should
 check out.

 I don't understand you completely. `r.gwflow` doesn't fail with the
 current trunk and it doesn't fail even with your changes now for me. Does
 it fail for you?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2750#comment:9>
GRASS GIS <https://grass.osgeo.org>