Re: [Flightgear-devel] Performance and initialization patch
Hi, weekly resubmit. New this week: o After scenery finishes loading: FGScenery::getPagerSingleton()-setMaximumNumOfObjectsToCompilePerFrame(1); Should help with excessive frame drops. Default is 4. o Integrated James Turner's fixes, thank you. o SGAtomic not longer used: big mem savings on win32 Usual content: o bigger zlib decompression buffer o nafree() returns if freeing NULL o throttle screen update rate on splash screen for single core machines o reduced memory usage for FGRunway o faster apt.dat, nav.dat awy.dat parsing My previous memory numbers were wrong, I was still using the buggy double taxiway allocation (I have 4 local copies of the code). With the SGAtomic changes and the reduced memory footprint of FGRunway the following memory usage was measured on ksfo (no random objects, win32), just running fgfs.exe, no params (i may have some non-standard preferences saved, they were the same for both runs anyway): original: 565MB this patch: 470MB Over some random terrain for which i have not downloaded terrain files and using ufo instead of c172: 338 231 This is after the splash screen disappears. The numbers oscilate +/- 10MB. It seems something is allocating and freeing memory just after loading. greetings, yon perf3.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi,
one little thing i was meaning to include but forgot. At the end of
fgMainLoop() add:
scenery_loaded = true;
}
if( ! scenery_loaded ) {
unsigned int tocompile =
FGScenery::getPagerSingleton()-getDataToCompileListSize();
unsigned int requests =
FGScenery::getPagerSingleton()-getFileRequestListSize();
char msg[60];
snprintf( msg, 59, loading scenery objects %2u / %2u, requests,
tocompile );
fgSplashProgress( msg );
}
fgRequestRedraw();
SG_LOG( SG_ALL, SG_DEBUG, );
}
For a nice little countdown of # of tiles left to load and compile.
greetings,
yon
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Dec 4, 2008 at 3:25 PM, Csaba Halász [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote: One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Somebody has recently switched some threading stuff over to OSG's classes, I wonder if we should throw out SGAtomic, SGReferenced, and SGSharedPtr in favor of OSG's implementation. Coincidentally, OpenThreads::Atomic doesn't have that align, it simply has a volatile long and presumably it works fine. -- Csaba/Jester Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. greetings, yon referenced.patch Description: Binary data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, i was testing on my local airport (coastal, less terrain) with ufo, let me test on inland airport (LEMD, madrid) with 172. Im running with the patch that reduces precision for fgrunway, no longer can we measure runway length in super-cords widths, only upto 10 nanometers ;) Memory (private bytes) measured with procexp.exe after scenery finishes loading. CVS: 499MB patched: 431MB hmm, over ocean: 291 361 hmm, i dont know what i measured before, maybe some other memory counter? my bad. Seems it is only saving around 70MB (on windows, unixes already have part of this memory saving). greetings, yon On Fri, Dec 5, 2008 at 5:28 PM, James Turner [EMAIL PROTECTED] wrote: On 5 Dec 2008, at 16:01, Yon Uriarte wrote: Excellent idea. With the patch and some other changes it saves 100MB over terrain, less over ocean. That's just after the scenery has finished loading, should be more over time. Good gracious. 100MB? That seems almost impossibly large. This is a change that needs to be pretty widely tested, but it sounds like a great improvement. James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 4 Dec 2008, at 02:58, Yon Uriarte wrote:thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways>, it's wasteful.Well, see my version in that regard.Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies.By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192.I would prefer not to reduce precision - I don't think the memory savings warrant it, and at least on some machines, the compiler is forced to generate many float->double or double->float conversions. FGRunway is notefficientfor size, but it's not costing us anything in real terms - unlike the start up time. And, again, I have pending work in this area that makes all of these issues go away completely, so unless there's an immediate benefit for the 1.99.x release, I would focus on some other area.One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload.After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs?Can't comment on that, I'm on GCC 4.0 on Mac where SGAtomic is falling-back to pthreads :(Here's my patch (including yours) to src/Airports: fg-apt-perf-james.patch Description: Binary data Regards,James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Dec 4, 2008 at 10:01 AM, James Turner [EMAIL PROTECTED] wrote: On 4 Dec 2008, at 02:58, Yon Uriarte wrote: thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways, it's wasteful. Well, see my version in that regard. I see, it's overall nicer. Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies. By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. I would prefer not to reduce precision - I don't think the memory savings warrant it, and at least on some machines, the compiler is forced to generate many float-double or double-float conversions. FGRunway is not efficient for size, but it's not costing us anything in real terms - unlike the start up time. Around 30MB. Didnt know you where working on changing the airport load code. Going for 8.50? IMHO there is little point in keeping the runway length in doubles. It's seldom used, it's just putting pressure on the swap trigger. We let pass 30MB here, 30MB there, 2 seconds here, .8 there and it adds up. I try to consider a 1Ghz pentium 3 with 1GB RAM as an oldish machine target that may run fg. Not to nitpick, im glad i can give something to fg. The startup time is what catched my attention even before taking off the ground :) And, again, I have pending work in this area that makes all of these issues go away completely, so unless there's an immediate benefit for the 1.99.x release, I would focus on some other area. I will, thanks for the hint. I can test your airport code, profile it and gladly nitpick on it's memory/cpu use ;) I've been considering changing the load code for apt and nav to use strod. Apparently sometimes atof is implemented as a wrapper of strod (dinkumware.com, dont know what the man pages say). It would save the walking copy of the line for spliting and some atof overhead. It would produce the typical char *p inner loop :) But im having fun with the 3dclouds and osg, so maybe later. One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Can't comment on that, I'm on GCC 4.0 on Mac where SGAtomic is falling-back to pthreads :( Here's my patch (including yours) to src/Airports: thanks Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On Thu, Dec 4, 2008 at 3:58 AM, Yon Uriarte [EMAIL PROTECTED] wrote: One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Somebody has recently switched some threading stuff over to OSG's classes, I wonder if we should throw out SGAtomic, SGReferenced, and SGSharedPtr in favor of OSG's implementation. Coincidentally, OpenThreads::Atomic doesn't have that align, it simply has a volatile long and presumably it works fine. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, thank you. I've keep working a bit on it. The airport ctor doesnt need to init the vectorxways, it's wasteful. Now it saves a few megabytes by removing unneeded parts from FGRunways (400k+ constructed) and using some string instead of string copies. By using those changes and also by using reduced precision on FGRunway members (double for length?) i was able to reduce sizeof(FGRunway)(win32) from 256 to 192. One big contributor to size is SGAtomic. On windows it's 32 bytes for a 4 byte counter. That makes SGReferenced 32 bytes, too, for an 8 bytes payload. After reading the docs on InterlockedIncrement (they say a 4 byte align is necessary) I tried recompiling with SGAtomic aligned on 4 bytes, but i got some quite obscure crashes inside ntsomething.dll called from malloc. Anyone knows why we need to align to 32 bytes (x86's cache line) and not 4 bytes as suggested by the docs? Thanks again, attached is a patch for the patch. May I ask for your patch? greetings, yon On Thu, Dec 4, 2008 at 2:38 AM, James Turner [EMAIL PROTECTED] wrote: On 1 Dec 2008, at 18:20, James Turner wrote: I will apply and test, sadly I am in the same situation as you for getting patches applied :) I've tested the apt loader / string split / patch, and everything seems to work - though I've complicated things by refactoring the runway / taxiway creation, to fix some style issues, and resolve a couple of problems: taxiways don't need a reciprocal created (and it's wasteful to do so), and runways weren't getting their airport set, which crashed some local code of mine. Regards, James perf2.patch.gz Description: GNU Zip compressed data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Sun, Nov 30, 2008 at 12:56 AM, Tim Moore [EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. No. Your request to don't use it in the global constructors is not sufficient. Shouldnt matter too much performance wise anyway :) I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) greetings, yon loader.patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 1 Dec 2008, at 18:00, Yon Uriarte wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) I will apply and test, sadly I am in the same situation as you for getting patches applied :) James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi On Mon, Dec 1, 2008 at 7:20 PM, James Turner [EMAIL PROTECTED] wrote: On 1 Dec 2008, at 18:00, Yon Uriarte wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) I will apply and test, sadly I am in the same situation as you for getting patches applied :) James haha, thank you. What's your patch about? Maybe we can swap patch tests :) yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Mon, Dec 1, 2008 at 7:00 PM, Yon Uriarte [EMAIL PROTECTED] wrote: I attach the patch for the airport, airway and navdb loaders. Also included is the patch to throttle the frame rate while loading the scenery at startup and to set the gzip input buffer to 64k (was 4k). I believe all of them make sense and are sufficient. I'd like to ask for them to get tested and eventually applied. I'll keep resubmiting them at 1 week intervals :) did some timings on the throttle patch to try and market it :) I got some unexpected results: All times in ms, dual-core pentium E2xxx @3.1GHz Affinity set to simulate single-core with: start /affinity 0x1 /B fgfs ... Throttle at 15fps throttled, no random objects, no affinity. 4096 4078 4074 not throttled, no random objects, no affinity 3029 3217 3012 throttled, no random objects, affinity 0x1 5498 5435 5457 not throtled, no random objects, affinity 0x1 4556 4502 4482 throttled, enabled random objects, no affinity 30009 29532 29005 29988 not throttled, enabled random objects, no affinity 38285 37927 37958 throttled, enabled random objects, affinity 0x1 33749 33518 34116 not throttled, enabled random objects, affinity 0x1 61120 57412 58443 it is faster for random objects (target case), but slower for all other cases. I suspect the osgDB threads are blocking waiting for the frame to upload their display lists. Anyway, throttled to 50fps now I get: throttled 50 , no random objects, no affinity 3176 3187 3168 throttled 50 , random objects, affinity 0x1 38455 37583 38273 Please set the frame limiter to 50, not15, when testing, I'll set it to that in next week's patch. yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Yon Uriarte wrote: Hi, On Sat, Nov 29, 2008 at 1:41 AM, Tim Moore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Nice. It is still doing a pointless function call. No. Your request to don't use it in the global constructors is not sufficient. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, it seems this message was deleted (over 40k). I cant find it on the archives so im resending it now with a compressed patch. Please ignore if this is a repost. -- this patch tries to speed up airways laoding. The strutils funcions are meaningfully commented and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. flightgear-patch.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 greetings, yon On Fri, Nov 28, 2008 at 11:09 AM, Yon Uriarte [EMAIL PROTECTED] wrote: Hi, it seems this message was deleted (over 40k). I cant find it on the archives so im resending it now with a compressed patch. Please ignore if this is a repost. -- this patch tries to speed up airways laoding. The strutils funcions are meaningfully commented and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. fg.rar Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On Fri, Nov 28, 2008 at 10:18 AM, Yon Uriarte wrote: Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 Am I misreading your stats? There doesn't seem to be any significant different between your two sets of timing data (?) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
hi, those are 2 consecutive samples of the new navaid.dat parser. Compare with the times in the previous posts. It has gone down from 520msec to 350msec. Not a big difference on a fast machine, but it was a very easy change. On slower machines it should add up. greetings, yon On Fri, Nov 28, 2008 at 5:25 PM, Curtis Olson [EMAIL PROTECTED] wrote: On Fri, Nov 28, 2008 at 10:18 AM, Yon Uriarte wrote: Hi, took a quick stab at navaid parsing. Also, i modified strutils::do_strip to avoid calling string::operator[] excessively. Results: Airport load time: 1769 Metar load time: 7 Navaid load time: 349 Airway load time: 726 Airport load time: 1770 Metar load time: 7 Navaid load time: 348 Airway load time: 728 Am I misreading your stats? There doesn't seem to be any significant different between your two sets of timing data (?) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi,
another little detail. In zfstream.cxx the input buffer for reading
buffered .gz files is set at page_size (4k). It is my understanding this
means files will be read at 4k chunks (uncompressed 4k). By changing the
multiplier to 16 (64k) or even 64 i could unscientifically measure a small
gain. I believe gzstream is used for terrain loading, too. I guess a value
of 16*page_size should be adecuate, not too small, small enough that it
might stay in the cache for the caller to process. This should save on
system calls, too.
Non scientific measurements, twice for each size:
original, 1 page buffer:
Airport load time: 1769
Metar load time: 7
Navaid load time: 349
Airway load time: 726
Airport load time: 1770
Metar load time: 7
Navaid load time: 348
Airway load time: 728
istream.gz buffer from 1 to 16 pages size
Airport load time: 1746
Metar load time: 7
Navaid load time: 343
Airway load time: 716
Airport load time: 1742
Metar load time: 8
Navaid load time: 343
Airway load time: 724
at 64 pages
Airport load time: 1728
Metar load time: 7
Navaid load time: 344
Airway load time: 720
Airport load time: 1736
Metar load time: 7
Navaid load time: 345
Airway load time: 728
Patch:
Index: zfstream.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/zfstream.cxx,v
retrieving revision 1.5
diff -u -r1.5 zfstream.cxx
--- zfstream.cxx 25 Jul 2008 18:35:42 - 1.5
+++ zfstream.cxx 28 Nov 2008 17:15:05 -
@@ -42,7 +42,7 @@
ibuffer(0)
{
// try {
-ibuf_size = page_size / sizeof(char);
+ibuf_size = 16*(page_size / sizeof(char));
ibuffer = new char [ibuf_size];
// } catch (...) {
//delete [] ibuffer;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Yon Uriarte wrote: Hi, logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) I've reworked the logstream changes a bit and checked this in. Thanks. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 26 Nov 2008, at 12:19, James Turner wrote: strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. Just had a thought here - it should be possible to use std::vector::swap() to pass in std::vectorFGRunway*, and avoid the ugly 'count' arguments. I'll do up a patch for this today/tonight. I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 27 Nov 2008, at 11:50, Yon Uriarte wrote: I changed it a bit, too. Now it passes the runways to the constructor and addRunways is private. But using swap sounds like the solution. It'll need 2 vectors in the apt.dat main loop, one with runways, the other one with taxis. Right, I think that makes sense. I sort of prefer to have a: void FGAirport::addRunwaysAndTaxiways(std::vectorFGRunway* aRunways, std::vectorFGRunway* aTaxiways) rather than constructor arguments, but that's a personal dislike of constructors with many arguments. Either way is acceptable! I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Changed the name to split_inplace and patching airways parsing to use it. Still testing and timing. Possibly will look at the fix parsing, too, it's slowish. Fair enough. Again, I may be changing how the data is loaded in the future, but short term gains are also good. Thanks, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, commenting inline. Im still programming a bit and measuring times. Patch later. On Wed, Nov 26, 2008 at 2:26 PM, Melchior FRANZ [EMAIL PROTECTED] wrote: Hi, * Yon Uriarte -- Wednesday 26 November 2008: this is a patch to speed up startup times and some other misc things. Thanks for taking care of that. Startup time is really a problem, made worse by the fact that one has to restart fgfs to use another aircraft. I'll leave commenting on the nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. I've renamed the functions and added meaningful comments. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. No, i dont think they should keep doing that. In the context of the file it's written in (strutils.cxx) you can easily compare the 2 functions and calculate in your head why the others are a cluster thing. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) WTF?? why? we are adults. Whatever, adult words removed. BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. Nothing i can do about that, let the CVS commiters pass a replace over the files. MSVS is a hard master. Or is there an option to tell it not to mess with my spaces? m. greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
- Yon Uriarte a écrit : Nothing i can do about that, let the CVS commiters pass a replace over the files. MSVS is a hard master. Or is there an option to tell it not to mess with my spaces? Tools Options Text editor C/C++ Tabs -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, On Thu, Nov 27, 2008 at 9:53 AM, James Turner [EMAIL PROTECTED] wrote: On 26 Nov 2008, at 12:19, James Turner wrote: strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. Just had a thought here - it should be possible to use std::vector::swap() to pass in std::vectorFGRunway*, and avoid the ugly 'count' arguments. I'll do up a patch for this today/tonight. I changed it a bit, too. Now it passes the runways to the constructor and addRunways is private. But using swap sounds like the solution. It'll need 2 vectors in the apt.dat main loop, one with runways, the other one with taxis. I agree with Melchior's comments about putting apt.dat specifics into SimGear, the split helpers can happily live in apt_loader.cxx. That way we'll know to delete them if I ever replace the file format. Changed the name to split_inplace and patching airways parsing to use it. Still testing and timing. Possibly will look at the fix parsing, too, it's slowish. Regards, James greetings, yon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, this patch tries to speed up airways laoding. The strutils funcions are meaningfully commened and renamed. It also does timings on the load times. My results: 2 runs no changes wrt. to last patch: Airport load time: 1607 Metar load time: 16 Navaid load time: 499 Airway load time: 1170 Airport load time: 1607 Metar load time: 16 Navaid load time: 483 Airway load time: 1185 --- after changes to airways loader. Airport load time: 1622 Metar load time: 8 Navaid load time: 499 Airway load time: 690 Airport load time: 1614 Metar load time: 8 Navaid load time: 505 Airway load time: 689 Airport load time: 1610 Metar load time: 8 Navaid load time: 498 Airway load time: 689 Airport load time: 1664 Metar load time: 8 Navaid load time: 510 Airway load time: 699 Airport load time: 1684 Metar load time: 7 Navaid load time: 513 Airway load time: 684 -- Then i noticed i had the files (*.dat) unpacked because i'd been peeking at the contents. After repacking i got the following times: Airport load time: 1806 Metar load time: 7 Navaid load time: 526 Airway load time: 732 Airport load time: 1790 Metar load time: 7 Navaid load time: 522 Airway load time: 721 Airport load time: 1793 Metar load time: 7 Navaid load time: 528 Airway load time: 721 greetings, yon On Thu, Nov 27, 2008 at 11:58 AM, Frederic Bouvier [EMAIL PROTECTED]wrote: Tools Options Text editor C/C++ Tabs Thank you, i hope there are no evil tabs now. FlightGear - Copy (2).patch Description: Binary data SimGear - Copy (2).patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and initialization patch
Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: nasal/misc.h: If p == 0 return, else call free(p). Dont go into the malloc lib for nothing, probably free() does this check 1st thing in most implementations, no need to test the malloc library. p == 0 happens, checked with debugger. logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? ViewPartitionNode, CameraGroup: Small compile fix for a OSG version with float matrices, instead of double. Tried to compile with float matrices to see if it affects speed, but the quantization is visible (aprox .5m) and the airplane jitters horribly. main.cxx: While showing the splash screen, limit the frame rate. I was getting 200fps at the splash screen, which is pointless wasteful, specially on single-core machines. On multicore one core is pegged at 100%, another is loading tiles. If you run with VBLANK on, on a fast single-core machine, it may not matter too much. Anyway, 15Hz redraws should be enough, quite possibly as low as 5Hz could be acceptable. Older computer owners should notice a difference. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) The most important changes are the apt.dat optimization, the logstream optimization and the splash screen throttling. On this 3Ghz dual core intel E2160 with hot disk-caches and --disable-random-objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. Going forward another big config issue I see is --enable-random-objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random-objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. regards, yon FlightGear - Copy.patch Description: Binary data SimGear - Copy.patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, * Yon Uriarte -- Wednesday 26 November 2008: this is a patch to speed up startup times and some other misc things. Thanks for taking care of that. Startup time is really a problem, made worse by the fact that one has to restart fgfs to use another aircraft. I'll leave commenting on the nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 26 Nov 2008, at 11:14, Yon Uriarte wrote: Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) Sounds good to me. strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? I suspect this is paranoia due to some of the more exotic OSG threading modes being less well tested. I believe I can be over-riden by the OSG_THREADING environment variable in any case. Tim Moore can hopefully say for sure. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) This is 'my' file, it's new in the codebase and could easily contain silly things. You patch only adds an operator, so I'm not sure if it's needed or not. dual core intel E2160 with hot disk-caches and --disable-random- objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. I would hold off airways unless you have an abundance of time (or look at random objects first), or if it's a quick change, since I'm planning some more drastic changes in that area, possibly including a file format change. If it's a quick win, go for it, of course. Going forward another big config issue I see is --enable-random- objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random- objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. Thanks for doing this, it's much appreciated. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
