* Drew -- Tuesday 24 May 2005 07:54:
> FlightGear takes nearly a minute to start up from my Windows build,
> and I'm just wondering if there's an easy way to shorten this if I'm
> not using all of flightgear's features. Is there one particular task
> that takes particularly long?
Because yesterday was the 200th bithday of the Wiener/Frankfurter/Hot-Dog
sausage, I add my mustard (German saying; does probably not translate well :-)
I know about the deficiencies of MICROS~1 Windos in general, but not about
CygWin/MinG. fgfs starts in about 35 seconds for me on Linux (2.4GHz).
Mathias and I did some profiling recently, after I had changed the starting
order and added the progress information. The most significant time sinks
are (as some pointed out already):
(1) loading airport and navigation data; very rough guess: ~ 45%
(2) initializing subsystems (atc, weather, ai, ...) ~ 30%
(3) creating MipMaps (no perceived delay, because it's done in another thread)
To speed things up other than with migrating to a sane system/OS, you could
for (1): cut down the databases to a bare minimum (they are just gzipped
ASCII files; unpack them, edit them, and AFAIK you don't even need
to compress them again; only remove complete chunks)
for (2): turn off as many subsystems as possible (/sim/atc/enabled=false, etc.)
for (3): use as few textures as possible; You can:
- edit material.xml and let it share textures (only one wood texture)
or start fgfs in the desert :-)
- use aircraft with few and small textures (hint: avoid the MD-11 :-)
- scale down textures
But all that makes the scenery uglier and is probably not what you
The gain is probably not worth it, anyway.
Finally: if you need to restart fgfs very often, because you are developing
something for/with it, you can preload and even pre-relocate it: Just run it
in gdb and never leave gdb. The code remains relocated in memory then and start
much quicker. I do this regularly.
Flightgear-devel mailing list