[Flightgear-devel] Re: FlightGear startup time
* 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 want. 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. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Norman Vine -- Tuesday 24 May 2005 14:05: > I guess I should mention the deficiencies of non MSoft OSs but > I will leave the *flames* for another time :-) Yeah, don't bother. 99% of Windows users don't know alternatives, but 99% of Linux/Unix users *do* know Windows. Of course, there are deficiencies in Unix too (hmm ... game support?). But while deciding for Windows is mostly a matter of ignorance and inertia, deciding for Unix is a matter of reason. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Martin Spott -- Thursday 26 May 2005 13:07: > In my eyes _dropping_ ASCII XML files from the distribution should considered > to be a no-go, Seconded. And then: it's *not* XML parsing that slows the startup process down so much! It's parsing two simple gzipped ASCII lists that are directly taken from X-Plane. Blowing them up to XML and then compiling them to a binary XML is pure nonsense. I'd rather go for the "cache a binary representation in $FG_HOME that is re-generated whenever necessary" method. Fears that this means less openness are completely unfounded and unreasonable. That's nothing else than having a binary representation in memory. The open format is still the only source of it, and every changed bit therein will take effect at the next start. But then again, the 35 seconds that I have to wait now don't kill me. :-} m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Melchior FRANZ -- Thursday 26 May 2005 14:00: > "cache a binary representation in $FG_HOME [...]" Or better even in /var/tmp/. BTW: this method isn't such a Great Idea[TM], as someone implied (and it wasn't Richard, who certainly knows that). It's rather the usual way to do things like these. sendmail does it (you have to compile the ascii files yourself), KDE does it: every config file is ASCII in good old MICROS~1 *.ini format; but behind the scenes, they are collected and compiled into a binary database by kbuildsycoca[1]. Most KDE users probably don't know that, and that's how it should be. The *rc files are still open. Nobody cares for the cached binary blob. And not many know it's internal format, although it's, of course, documented. m. [1] "KDE: build system configuration cache" :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Gerard ROBIN -- Thursday 26 May 2005 14:12: > Le jeudi 26 mai 2005 à 14:00 +0200, Melchior FRANZ a écrit : > > * Martin Spott -- Thursday 26 May 2005 13:07: > > Seconded. And then: [...] > Thanks Mathias And thanks Gerard for thanking Mathias as a response to my message. m. :-} ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
> > * 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. The problem is Cygwin emulates Posix streams and this adds significantly to the overhead of stream based ops The XML files require *many* stream ops This addirional overhead is not present in MingW in that it uses native Win32 streams. I guess I should mention the deficiencies of non MSoft OSs but I will leave the *flames* for another time :-) Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On Tue, 24 May 2005 14:26:17 +0200, Melchior wrote in message <[EMAIL PROTECTED]>: > * Norman Vine -- Tuesday 24 May 2005 14:05: > > I guess I should mention the deficiencies of non MSoft OSs but > > I will leave the *flames* for another time :-) > > Yeah, don't bother. 99% of Windows users don't know alternatives, but > 99% of Linux/Unix users *do* know Windows. Of course, there are > deficiencies in Unix too (hmm ... game support?). But while deciding > for Windows is mostly a matter of ignorance and inertia, ..you forgot viscosity here. ;o) > deciding for Unix is a matter of reason. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Believe me, guys, if I could use Linux for this application, I would...I am much more familiar with developing in Linux than Windows. Unfortunately, that isn't an option for me in this case. Drew On 5/24/05, Melchior FRANZ <[EMAIL PROTECTED]> wrote: > * Norman Vine -- Tuesday 24 May 2005 14:05: > > I guess I should mention the deficiencies of non MSoft OSs but > > I will leave the *flames* for another time :-) > > Yeah, don't bother. 99% of Windows users don't know alternatives, but 99% of > Linux/Unix users *do* know Windows. Of course, there are deficiencies in Unix > too (hmm ... game support?). But while deciding for Windows is mostly a matter > of ignorance and inertia, deciding for Unix is a matter of reason. ;-) > > m. > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On Tuesday 24 May 2005 13:45, Melchior FRANZ wrote: > > (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) > Maybe this is a good time time to formulate a though I've had for some time now: With rumours of a possible 1.0.0 version sometime in 2005, I don't think it's a good time to start digging into the basic architecture of FlightGear. However, once version 1.0 is out, wouldn't that be an excellent opportunity to carefully scrutinize the core architecture of FlightGear and redesign it with the goal of ruducing interdependencies, memory requirements, and improving startup time? Any thoughts/comments? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Drew wrote: > Believe me, guys, if I could use Linux for this application, I > would...I am much more familiar with developing in Linux than Windows. > Unfortunately, that isn't an option for me in this case. Well, I wouldn't use Windows either and I actually don't. But I installed the latest release binary of FG on my life-mates/girl-friends PeeCee and I acknowledge that it works excellent. The main drawback appears to lie in different environments that try to emulate Unix features. The MSVC binary instead does a great job, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Le mardi 24 mai 2005 à 17:42 +0200, Durk Talsma a écrit : > On Tuesday 24 May 2005 13:45, Melchior FRANZ wrote: > > > > (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) > > > > Maybe this is a good time time to formulate a though I've had for some time > now: With rumours of a possible 1.0.0 version sometime in 2005, I don't think > it's a good time to start digging into the basic architecture of FlightGear. > However, once version 1.0 is out, wouldn't that be an excellent opportunity > to carefully scrutinize the core architecture of FlightGear and redesign it > with the goal of ruducing interdependencies, memory requirements, and > improving startup time? > > Any thoughts/comments? > > Cheers, > Durk > > may be i am the only one to be satisfied with startup time: less than 50 secondes: -->metar -->geometry 1280*896 ->nmea socket (atlas) -->ai (carrier Nimitz in Mediterranean sea) -->High detailed and textured aircraft (3 Mb) with 3D panel/instruments in addition to every default -->fgfs parameters The main difficulties are rather coming from the tiles loading during flight. Which could be tuned. If possible. fgfs running with Linux 2.6.11 > > Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Durk Talsma wrote: Maybe this is a good time time to formulate a though I've had for some time now: With rumours of a possible 1.0.0 version sometime in 2005, I don't think it's a good time to start digging into the basic architecture of FlightGear. However, once version 1.0 is out, wouldn't that be an excellent opportunity to carefully scrutinize the core architecture of FlightGear and redesign it with the goal of ruducing interdependencies, memory requirements, and improving startup time? I've been working on this regularly the in the past. It's not easy and I doubt it will gain much. However, I think the current airport reading code is just a mixture of code from the past adopted to read the new data. So it could be the code currently is reading one file more than once ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On Tuesday 24 May 2005 18:32, Erik Hofman wrote: > Durk Talsma wrote: > > Maybe this is a good time time to formulate a though I've had for some > > time now: With rumours of a possible 1.0.0 version sometime in 2005, I > > don't think it's a good time to start digging into the basic architecture > > of FlightGear. However, once version 1.0 is out, wouldn't that be an > > excellent opportunity to carefully scrutinize the core architecture of > > FlightGear and redesign it with the goal of ruducing interdependencies, > > memory requirements, and improving startup time? > > I've been working on this regularly the in the past. It's not easy and I > doubt it will gain much. > > However, I think the current airport reading code is just a mixture of > code from the past adopted to read the new data. So it could be the code > currently is reading one file more than once ... > Erik, you are of course in a far better position to judge this than me. As far as I know, though there still seem to be a few design issues with the FlightGear architecture that have evolved into what they are today, yet being slightly less than ideal. For example, back in January (Jan 16) David Luff and I descussed dependencies and counter dependencies on location, weather, wind and location. I also seem to remember a similar depency and counter dependency between startup location, time, and sun position. Another issue that has been brought up a number of times is the ascii vs binary file format disussion. While I absolutely believe that ascii/xml files are ideal for development work, combined they may have a pretty big impact on loading time. Therefore, would it be an idea to 'precompile' the .xml files and use a binary version during runtime? I'm personally considering doing this for the trafficManager files, because the parsing, initialization, and checking against unknown airports is taking huge amounts of time. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
> > Durk Talsma wrote: > > > > Erik, you are of course in a far better position to judge this than me. As > far > as I know, though there still seem to be a few design issues with the > FlightGear architecture that have evolved into what they are today, yet being > slightly less than ideal. For example, back in January (Jan 16) David Luff > and I descussed dependencies and counter dependencies on location, weather, > wind and location. I also seem to remember a similar depency and counter > dependency between startup location, time, and sun position. > > Another issue that has been brought up a number of times is the ascii vs > binary file format disussion. While I absolutely believe that ascii/xml files > are ideal for development work, combined they may have a pretty big impact on > loading time. Therefore, would it be an idea to 'precompile' the .xml files > and use a binary version during runtime? I'm personally considering doing > this for the trafficManager files, because the parsing, initialization, and > checking against unknown airports is taking huge amounts of time. > > Cheers, > Durk > > I am, mainly a user. I do like fgfs, because of, direct access to data and parameters. <===It is not a game==> The idea to precompile xml goes against that concept. I think: on the game side, it is existing many others products which could answer to "quick startup" and answer the players needs (products mainly closed) We can accept a delay when loading (the performance depends on the hard and soft configuration). -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Gerard ROBIN writes: > > > > Durk Talsma wrote: > > >> > > Another issue that has been brought up a number of times is the ascii vs > > binary file format disussion. While I absolutely believe that ascii/xml > > files > > are ideal for development work, combined they may have a pretty big impact > > on > > loading time. Therefore, would it be an idea to 'precompile' the .xml files > > and use a binary version during runtime? I'm personally considering doing > > this for the trafficManager files, because the parsing, initialization, and > > checking against unknown airports is taking huge amounts of time. > > > > Cheers, > > Durk > > > > > I am, mainly a user. > I do like fgfs, because of, direct access to data and parameters. > <===It is not a game==> > The idea to precompile xml goes against that concept. > > I think: > on the game side, it is existing many others products which could answer > to "quick startup" and answer the players needs (products mainly > closed) > > We can accept a delay when loading (the performance depends on the hard > and soft configuration). http://baron.flightgear.org/pipermail/flightgear-devel/2003-September/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. Thaks for bringing this up again :-) Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Norman Vine wrote: http://baron.flightgear.org/pipermail/flightgear-devel/2003-September/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. I've had this in the back of my mind ever since you brought it up, but not many people (including XML experts) seem to like binary XML. I'm still undecided about it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
> -Original Message- > Erik Hofman > Norman Vine wrote: > > > > http://baron.flightgear.org/pipermail/flightgear-devel/2003-Se ptember/021434.html > > I don't see the XML files as being any different then any other source file > and > source code needs to be compiled. > >I've had this in the back of my mind ever since you brought it up, but >not many people (including XML experts) seem to like binary XML. I'm >still undecided about it. > >Erik Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. This could be transparent to the user (they simply edit the ASCII version), it simply causes the startup time to be longer the next time around, but if no changes are made then there is no time penalty. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Le jeudi 26 mai 2005 à 09:35 +0100, Richard Bytheway a écrit : > > -Original Message- > > Erik Hofman > > Norman Vine wrote: > > > > > > > http://baron.flightgear.org/pipermail/flightgear-devel/2003-Se > ptember/021434.html > > > > I don't see the XML files as being any different then any other source file > > and > > source code needs to be compiled. > > > >I've had this in the back of my mind ever since you brought it up, but > >not many people (including XML experts) seem to like binary XML. I'm > >still undecided about it. > > > >Erik > > Would it be possible to have a compiled form stroed on disk, which is > automatically regenerated on startup of FGFS based on rules similar to make. > If the ASCII version is newer than the compiled version, rebuild the compiled > version. > This could be transparent to the user (they simply edit the ASCII version), > it simply causes the startup time to be longer the next time around, but if > no changes are made then there is no time penalty. > > Richard > This goes to an answer and an advantage for the PLAYERS. Which is not in my sense the fundamental idea we have of FGFS. I am a LINUX user i like the open access to everything. Ten years ago when i ought to use and work on windows i did not like that closed system, and was happy when LINUX went up. May be, presents windows users don't know that existing advantage. Don't go back to the "DARK SIDE". Any way if a day that "functionality" is implemented, it must be an option. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
"Richard Bytheway" wrote: > Would it be possible to have a compiled form stroed on disk, which is > automatically regenerated on startup of FGFS based on rules similar > to make. If the ASCII version is newer than the compiled version, > rebuild the compiled version. This is a very interesting approach that you present here - and probably the only one that doesn't destruct the whole idea of having human-adaptable configuration files. In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Martin Spott writes: > > "Richard Bytheway" wrote: > > > Would it be possible to have a compiled form stroed on disk, which is > > automatically regenerated on startup of FGFS based on rules similar > > to make. If the ASCII version is newer than the compiled version, > > rebuild the compiled version. > > This is a very interesting approach that you present here - and > probably the only one that doesn't destruct the whole idea of having > human-adaptable configuration files. In my eyes _dropping_ ASCII XML > files from the distribution should considered to be a no-go, Dropping the ASCII XML files from the distribution is jsut as likely and no less user friendly then dropping the source code files from the distribution. Just use the source Luke :-) That said this is an excellent idea. But I think that unlike C++ source binary XML 'decompiles' into ASCII easily :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Le jeudi 26 mai 2005 à 14:00 +0200, Melchior FRANZ a écrit : > * Martin Spott -- Thursday 26 May 2005 13:07: > > In my eyes _dropping_ ASCII XML files from the distribution should > > considered > > to be a no-go, > > Seconded. And then: it's *not* XML parsing that slows the startup process down > so much! It's parsing two simple gzipped ASCII lists that are directly taken > from X-Plane. Blowing them up to XML and then compiling them to a binary XML > is pure nonsense. I'd rather go for the "cache a binary representation in > $FG_HOME that is re-generated whenever necessary" method. Fears that this > means > less openness are completely unfounded and unreasonable. That's nothing else > than having a binary representation in memory. The open format is still the > only source of it, and every changed bit therein will take effect at the next > start. But then again, the 35 seconds that I have to wait now don't kill me. > :-} > > m. > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Thanks Mathias Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
"Norman Vine" wrote: > Martin Spott writes: >> This is a very interesting approach that you present here - and >> probably the only one that doesn't destruct the whole idea of having >> human-adaptable configuration files. In my eyes _dropping_ ASCII XML >> files from the distribution should considered to be a no-go, > Dropping the ASCII XML files from the distribution is jsut as likely > and no less user friendly then dropping the source code files from > the distribution. I totally disagree. The C/C++ source code is solely for building the executable binaries. For some serious reasons the runtime configuration has been swapped out to an XML framework to enable _everyone_, including Joe Average User to adjust their local copy of FlightGear to their very special 'needs'. The distinct separation of the user-configurable part into a human readable format is one of the major achievements in the development of FlightGear over the past years. Do you really want to turn the clock back ? BTW, as nice as CWXML might be, it adds yet another library dependency to FlightGear - one of the major reason, why the use of Metakit had been abandoned in the past. > Just use the source Luke :-) Yes, I do right on the track to figure how much effort it would be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC as compiler on _every_ supported Unix platform. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Le jeudi 26 mai 2005 à 14:12 +0200, Gerard ROBIN a écrit : > Le jeudi 26 mai 2005 à 14:00 +0200, Melchior FRANZ a écrit : > > * Martin Spott -- Thursday 26 May 2005 13:07: > > > In my eyes _dropping_ ASCII XML files from the distribution should > > > considered > > > to be a no-go, > > > > Seconded. And then: it's *not* XML parsing that slows the startup process > > down > > so much! It's parsing two simple gzipped ASCII lists that are directly taken > > from X-Plane. Blowing them up to XML and then compiling them to a binary XML > > is pure nonsense. I'd rather go for the "cache a binary representation in > > $FG_HOME that is re-generated whenever necessary" method. Fears that this > > means > > less openness are completely unfounded and unreasonable. That's nothing else > > than having a binary representation in memory. The open format is still the > > only source of it, and every changed bit therein will take effect at the > > next > > start. But then again, the 35 seconds that I have to wait now don't kill > > me. :-} > > > > m. > > > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@flightgear.org > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > 2f585eeea02e2c79d7b1d8c4963bae2d > > > > > Thanks Mathias > > > > Gerard I was meaning ==> Thanks Melchior > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Richard Bytheway wrote: > Would it be possible to have a compiled form stroed on disk, which > is automatically regenerated on startup of FGFS based on rules > similar to make. If the ASCII version is newer than the compiled > version, rebuild the compiled version. Sorry, but that sounds dumb. Wouldn't it be a better idea to try to figure out why it is slow in the first place before making all our configuration files non-editable? We really don't have that much XML to parse at startup; if it's really a performance limitation, then it's because we're doing something slow with our XML parsing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 04:32 pm, Andy Ross wrote: > > Would it be possible to have a compiled form stroed on disk, which > > is automatically regenerated on startup of FGFS based on rules > > similar to make. If the ASCII version is newer than the compiled > > version, rebuild the compiled version. > > Sorry, but that sounds dumb. Wouldn't it be a better idea to try to > figure out why it is slow in the first place before making all our > configuration files non-editable? How so? Python does it by compiling a new *.pyc everytime there is a change to the associated *.py file. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 01:43 pm, Ampere K. Hardraade wrote: > How so? Python does it by compiling a new *.pyc everytime there is a > change to the associated *.py file. > > > > Ampere Beside, you don't compile Flightgear everytime you run it. You compile Flightgear when there is a change in the source. Compiling scripts on a as-needed basis would be similar, if not the same. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Martin Spott writes: > > "Norman Vine" wrote: > > > Just use the source Luke :-) > > Yes, I do right on the track to figure how much effort it would > be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC > as compiler on _every_ supported Unix platform. You mean gcc isn't supported on IRIX ?? Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
"Norman Vine" wrote: > You mean gcc isn't supported on IRIX ?? Once I had GCC on IRIX and I spent numerous hours trying to build FlightGear, dealing with dozends of ICE's. Now I use MIPSpro and I admit that I don't want to go back, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Andy Ross > Sent: 26 May 2005 17:33 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Re: FlightGear startup time > > > Richard Bytheway wrote: > > Would it be possible to have a compiled form stroed on disk, which > > is automatically regenerated on startup of FGFS based on rules > > similar to make. If the ASCII version is newer than the compiled > > version, rebuild the compiled version. > > Sorry, but that sounds dumb. Wouldn't it be a better idea to try to > figure out why it is slow in the first place before making all our > configuration files non-editable? > > We really don't have that much XML to parse at startup; if it's really > a performance limitation, then it's because we're doing something slow > with our XML parsing. > > Andy Yes, figuring out why it is slow in the first place is a good idea, and I see from later messages that you have done some investigation into this already. But I don't think it is a dumb idea per se. Maybe I didn't elaborate enough: I suggest keeping the editable configuration files, exactly as they are now. When FlightGear starts, and it want to use one of the config/data files, it first looks for a binary (compiled) representation of the file. If it cannot find it, it reads the editable version (slowly), and in the process creates the "compiled" version and stores it somewhere on disk. If the compiled version exists, the file timestamp is compared with the relevant editable "source" file. If the compiled version is newer, then it is used, if the compiled version is older than the editable file then the compiled version is recreated as if it didn't exist. I guess that a better description might be a "pre-parsed disk based cache of the Airport and Navigation data, and possibly the configuration files". On my Cygwin system here (Athlon 1GHz, 384MB RAM, Windows 2000) CVS from 9am this morning (UK time) startup timings for all defaults are: Elapsed Time (s)Event - 0 Start 3 Splash Screen Up 105 Airport and Nav Data done 252 Aircraft Loaded 258 Sky done 260 Subsystems done 341 Ready to fly So the bulk of the time is in loading the Airport and Nav data, and the aircraft. I shall try your patches and report what difference they make. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Arnt Karlsen wrote: On Tue, 24 May 2005 14:26:17 +0200, Melchior wrote in message <[EMAIL PROTECTED]>: * Norman Vine -- Tuesday 24 May 2005 14:05: I guess I should mention the deficiencies of non MSoft OSs but I will leave the *flames* for another time :-) Yeah, don't bother. 99% of Windows users don't know alternatives, but 99% of Linux/Unix users *do* know Windows. Of course, there are deficiencies in Unix too (hmm ... game support?). But while deciding for Windows is mostly a matter of ignorance and inertia, ..you forgot viscosity here. ;o) Right, Windows floats which is why it's better for Norman's marine research work. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
