Hamish wrote:
After about 10 seconds of testing I discovered that it would be useful to
add a G_sleep(3) as well.
For what reason? To give the GUI time to show itself?
which then makes me wonder why it takes so long to start up, even
the second time in a row, when it should all still be cached, it is
seemingly not so fast on an otherwise fast computer.
What do you mean by "start up"? The time until the windows appear?
I added some debug statements to the top levels of wxgui.py, to see
where the delays appear. The break down is ~0.6 seconds for the import
statements, ~0.2 seconds to create and show the splash screen, ~1.5
seconds for the call to GMFrame() in GMApp.OnInit(), resulting in ~2.3
seconds in total for the startup (i.e. until app.MainLoop() is
called).
FWIW, I don't normally see the splash screen; changing the wx.Yield()
call to wx.SafeYield() causes it to appear consistently. Using
wx.SafeYield() is probably a good idea for reasons of robustness;
recall the problems caused by calling "update" in gis.m (progress bar)
and NVIZ (Save Max. Res. PPM).
hmmm,
svn/grass65$ find | grep '\.pyc$'
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/gui_modules/globalvar.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/images/__init__.pyc
./dist.i686-pc-linux-gnu/etc/wxpython/icons/__init__.pyc
./swig/python/NumPtr.pyc
./swig/python/python_grass6.pyc
shouldn't wxgui.py byte-compile itself into wxgui.pyc the first time
it is run?
Modules which are imported should byte-compile themselves, provided
that the permissions allow it. But Python files which are run as
__main__ (i.e. "scripts") aren't byte-compiled.
(as this is portable and after installation the user might
not have permissions to write the file, so should a 'python wxgui.py
--test' or something be added to the Makefile to get the .pyc built/
installed?)
Python.make has the following pattern rule:
%.pyc: %.py
$(PYTHON) -m py_compile $<
So you should be able to use:
$(MAKE) $(ETCDIR)/wxgui.pyc
to generate a .pyc file during the build process.
--
Glynn Clements <glynn@gclements.plus.com>