From: Yon U. <yon...@gm...> - 2008-12-04 09:48:38
|
Hi, On Thu, Dec 4, 2008 at 10:01 AM, James Turner <zak...@ma...> 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 vector<xways>, 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 |