I've run some profiling tools against FlightGear and noticed that FlightGear spends lots of time dealing with the navaid database files under $FG_ROOT/Navaids, I guess that most of the time is actually spent parsing the ascii format data files.Being someone who compiles FG sometimes > 20 times a day, this is somewhat inconvenient for me, as well as mostly unnecessary, as I won't require the navdb most of the time.However, I understand the reason for not using binary file formats,Apart from the idea to provide a command line parameter to disable navdb db parsing, I also wondered whether it might be a good idea to try to reduce loading times by simply adding support for caching/pre-compilation functionality for such plaintext data to FlightGear, so underlying data files would still remain in plaintext format, while one would have the advantage of increased processing speed.This could actually be relatively easily implemented, as one could simply use a general class for the database and its fields and then directly serialize the data to a binary file whenever the timestamp of the serialized file doesn't match the timestamp of the actual navdb archives that contain the plaintext files.That way, FlightGear would only have to actually read in the plaintext version of these files if these have changed since the last "caching" took place, if they were NOT changed, FG could simply use the serialized object data, which should be much faster than parsing everything each startup.What do you think ?

The startup time is currently discussed on the devel list.Your idea about the timestamped binary database is the good I think (thats how I would do because there is no portability problem when the client compiles his own db).Perhaps you should post on the devel list ;)Harald.

This issue is being addressed right now.

>The startup time is currently discussed on the devel list.>>Your idea about the timestamped binary database is the good I>think (thats how I would do because there is no portability>problem when the client compiles his own db).I have looked up the discussions on the devel list, quite lengthy meanwhile.However, I made also first attempts using the described serialization approach: it's indeed a signifant reduction in startup time, even without having applied the patches from the devel list.But as I am not familiar with any serialization libraries other than boost (www.boost.org) I am not sure whether that'll be so warmly received, simply because boost is quite a dependency, however once it's compiled it's available.Maybe one should look for some other small serialization library, though.