[GRASS-dev] [GRASS GIS] #3293: r.texture: very slow when size is increased
GRASS GIS
trac at osgeo.org
Tue Feb 21 01:53:04 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 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.
>
> Might be interesting to benchmark where exactly most time is lost. Any
hints on how to do that ?
You could use profiling tools, e.g. pprof.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3293#comment:3>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list