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
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 =
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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,
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
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)
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
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
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
- 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/
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
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:
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
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
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)
29 matches
Mail list logo
