Julian Foad writes:
> Well, you've improved it. You've made it print to a local buffer
> in the object, so that memory is at least persistent after the call
> returns. However, that buffer is already used for make_string() so
> code like this:
>
> sprintf(dest, "%s = %s", getPath(), ge
Norman Vine writes:
[about SGPropertyNode::getPath]
> >Inside the main loop, it's used only for things like interactive
> >display in the property browser or through a network interface. It's
> >getStringValue where the slowdowns happen (we were talking about that
> >at the same time).
>
Jim Wilson writes:
>
>Norman Vine <[EMAIL PROTECTED]> said:
>
>> but see
>> FGViewMgr::update (double dt)
>>
>
>Yes, all those should be moved to nodes in the view class.
>How did this look in the last profiling run?
Can't remember
FWIW - I don't really trust the profiler with Cygwin as I hav
Norman Vine <[EMAIL PROTECTED]> said:
> but see
> FGViewMgr::update (double dt)
>
Yes, all those should be moved to nodes in the view class. How did this look
in the last profiling run?
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David Megginson writes:
>
>Norman Vine writes:
>
> > as far as I am concerned creating an ASCII property path
> > is a waste of time and should not be used anywhere inside
> > the 'main loop'.
>
>Inside the main loop, it's used only for things like interactive
>display in the property browser or
Norman Vine writes:
> as far as I am concerned creating an ASCII property path
> is a waste of time and should not be used anywhere inside
> the 'main loop'.
Inside the main loop, it's used only for things like interactive
display in the property browser or through a network interface. It's
David Megginson writes:
>
>That's what I had thought as well, but it turned out not to be the
>case. The string constructor is expensive, and we ended up using lots
>(and lots and lots of them), running, as we were, 30-100 iterations
>per second through hundreds of properties. Switching from str
Julian Foad writes:
> These sorts of difficulties with (char *) strings, especially not
> being able to pass them by value in any simple way, are the reasons
> why the "string" class has come to exist. THE "STRING" CLASS IS VERY
> EFFICIENT! (I'm speaking to everyone; I'm sure David already
