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(),
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).
I
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:
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
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]
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 have learned
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 string
