[GRASS-dev] Raster format and dual function module

[Hamish]

> > > For the time being, it would be better to see if we can improve
> > > the situation with some minor changes to a few key areas. It would
> > > help if someone has the time to build GRASS with profiling support
> > > and actually profile some common usage patterns.
> > 
> > You don't need to build with any special profiling support to try,
> > (!)
> > 
> > Run from valgrind, save interim results to a file using the
> > callgrind plugin, then visualize that file with KCachegrind.
> > 
> > see  http://kcachegrind.sourceforge.net/cgi-bin/show.cgi
> 
> In which case, it would be useful if someone could use that to analyse
> some common usage cases.

could you write some precise/focused command line examples of "common"
or likely intensive operations? (using spearfish)

then we can all test & share results. (e.g. where additional 64bit
overhead slows things down vs 32bit, bottlenecks in Mac vs Cygwin, etc)


> Cases which involve more than one process (e.g. d.*, or v.* when used
> with a separate DBMS server) are harder to analyse.
> 
> If it turns out that the separate null file is a signficant
> performance issue, we need to consider a migration plan for embedding
> nulls (e.g. if 6.3 can write out rasters with embedded nulls, do we
> need 6.2 to be able to read them?).

presumably FCELL and DCELL can use nan inline to identify NULL, CELL
needs something else?



Hamish