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, vector<runway> 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=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
