I have noticed in the last week(s) in grass 6.4svn -text mode that there
is some ~250ms delay at the GRASS terminal when I hit <enter>. Restarting
in GRASS 6.3.0 the response is instant, as is the normal linux terminal
prompt.
The CPU monitor jumps to 100% for an instant, holding down <enter> stalls
the terminal after 10-15 lines or so as the CPU is pegged at 100%.
lib/init/prompt.sh (given by $PROMPT_COMMAND) hasn't changed in 2 years.
I don't see any highly suspicious changes to g.gisenv/main.c.
Was it some change in libgis then?
I have noticed in the last week(s) in grass 6.4svn -text mode that there
is some ~250ms delay at the GRASS terminal when I hit <enter>. Restarting
in GRASS 6.3.0 the response is instant, as is the normal linux terminal
prompt.
The CPU monitor jumps to 100% for an instant, holding down <enter> stalls
the terminal after 10-15 lines or so as the CPU is pegged at 100%.
lib/init/prompt.sh (given by $PROMPT_COMMAND) hasn't changed in 2 years.
I don't see any highly suspicious changes to g.gisenv/main.c.
Was it some change in libgis then?
"unset PROMPT_COMMAND" fixes it of course.
what gives?
Try --without-gdal.
Here:
# 7.0, with GDAL
$ time for (( i = 0; $i < 1000 ; i=i+1 )) ; do g.gisenv MAPSET ; done >/dev/null
real 0m6.891s
user 0m4.893s
sys 0m2.083s
# 7.0, without GDAL
$ time for (( i = 0; $i < 1000 ; i=i+1 )) ; do g.gisenv MAPSET ; done >/dev/null
real 0m1.260s
user 0m0.390s
sys 0m0.703s
GDAL is written in C++. Any statically-allocated objects have their
constructors run when the library is loaded, and their destructors run
when it is unloaded, even if no library functions are ever called.
GDAL also links against a number of other libraries, possibly a large
number of them, some of which may have similar issues.
Hmm. We might want to allow the r.external support (i.e. linking
libgis against GDAL) to be enabled/disabled separately from the use of
GDAL by lib/proj and r.{in,out}.gdal.
On Fri, Sep 26, 2008 at 2:34 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
Try --without-gdal.
Here:
# 7.0, with GDAL
...
# 7.0, without GDAL
...
The timing differences are striking.
Hmm. We might want to allow the r.external support (i.e. linking
libgis against GDAL) to be enabled/disabled separately from the use of
GDAL by lib/proj and r.{in,out}.gdal.
Could the GRASS-GDAL-Plugin-autoload mechanism adapted
somehow (of course that's the reverse direction)? The GRASS plugin
is only loaded on demand. This would slow down the command using
it but for r.external and r.{in,out}.gdal it might be irrelevant since
usually performed only one time.
> Hmm. We might want to allow the r.external support (i.e. linking
> libgis against GDAL) to be enabled/disabled separately from the use of
> GDAL by lib/proj and r.{in,out}.gdal.
Could the GRASS-GDAL-Plugin-autoload mechanism adapted
somehow (of course that's the reverse direction)? The GRASS plugin
is only loaded on demand. This would slow down the command using
it but for r.external and r.{in,out}.gdal it might be irrelevant since
usually performed only one time.
Loading GDAL dynamically shouldn't be too much of a problem; r.in.gdal
used to do this (gdalbridge.[ch]), although I wouldn't use that
specific code).
> Could the GRASS-GDAL-Plugin-autoload mechanism adapted
> somehow (of course that's the reverse direction)? The GRASS plugin
> is only loaded on demand. This would slow down the command using
> it but for r.external and r.{in,out}.gdal it might be irrelevant since
> usually performed only one time.
Loading GDAL dynamically shouldn't be too much of a problem; r.in.gdal
used to do this (gdalbridge.[ch]), although I wouldn't use that
specific code).
I'll look into it.
Done in r33559.
By default, GDAL is loaded at run-time, but you can force direct
linking with "make GDAL_DYNAMIC=", or disable the GDAL support
altogether with "make GDAL_LINK=".
With run-time loading, the g.gisenv timings are comparable to the
non-GDAL case.