[GRASS-dev] Re: a better console and better diff

[Hamish]

Dylan:
> I wonder if this is a byte-code compiling thing... the first time
> GRASS was run with the new modules = slow, closing and opening again =
> fast?
> 
> looking at the output in top, I could see that a process
> called 'python' was using 99% of CPU, and about 3% of available
> memory. Nothing else looked suspicious.

could be. I'm not sure what else could python be up to?

just to note: the first time you start it everything (including python and
libraries) have to be read from the disk which takes a little while. The
second time it is likely to still be cached in memory so cpu or ram bound,
not disk i/o bound.


also, for installed versions it's important that the .pyc byte compiled
binaries are created at build time, as once installed the user starting
grass probably won't have write permission to $GISBASE.

I just rebuilt to confirm if that's happening -- yep, they get built.

[If they weren't you'd have to start grass once as root to get the .pyc
files actually written to disk, but a "make check" no-op could be run as
part of the build process to create them before 'make install' or the
package installation. AFAIK they are portable (within reason).]

I've got no idea how to test if the installed versions are up-to-date
& so not rebuilt even though on disk. maybe run as root and see if the
timestamp on the installed ones update?? anyway if you have modified
wxgui.py and don't have write permission to $GISBASE then you may have
to wait for it each time.


Hamish