[GRASS-dev] [GRASS GIS] #3293: r.texture: very slow when size is increased

GRASS GIS trac at osgeo.org
Tue Feb 21 02:07:34 PST 2017


#3293: r.texture: very slow when size is increased
--------------------------+-----------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.4.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.texture speed
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------

Comment (by mlennert):

 Replying to [comment:3 mmetz]:
 > Replying to [comment:2 mlennert]:
 > > Replying to [comment:1 mmetz]:
 > > > Replying to [ticket:3293 mlennert]:
 > [...]
 > > > >
 > > > > It would be great if this could somehow be accelerated.
 > > >
 > > > Maybe by processing moving windows in parallel, at the cost of
 allocating / freeing memory for each moving window.
 > >
 > > Yes, I've thought about this as well. This seems like a perfect
 example of a module that could profit from parallelisation across as many
 cores/threads the user choses. Memory usage is very low, so this will not
 be a bottleneck (except for large images as the module still reads in the
 entire data, no ?). And allocation only has to happen once at the
 beginning, and then you can just use the allocated window throughout, or ?
 >
 > No, because if you process moving windows in parallel, you process
 several moving windows at the same time. Therefore you would need to
 allocate + free memory for each moving window, otherwise the different
 moving windows would overwrite each other's results.

 Yes, but you would only need one window per process, and you would only
 allocate each process window once, at the beginning, or ?

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



More information about the grass-dev mailing list