Performance issues

[TheTom]

i.e. 80% is spent in Shiva alone.

That's the way it should be as if not changing anything there should only performed rendering which is done by Shiva.

But even without looking at the ShivaVG implementation, this is something where "lazy" rendering would obviously improve things significantly because the texture would only need to be redrawn once it gets updated.

I'm currently working on this one. I have some working code, but it's very hackish. So if anyone has experiences in render-to-texture on demand in OSG any hint is appreciated

So reducing the amount of nodes that we write to the property tree,

I'm also thinking about supporting SVG path syntax where the whole path is specified using one string instead of a property for each command/coordinate.

[Hooray]

If groups could be updated on demand and rendered to a temporary/intermediate texture, before getting merged with the textures from the other groups, that should definitely help us speed up things significantly. Maybe we could even support some form of "meta" information to mark groups as "static" or "dynamic" - so that the canvas knows if children are likely to change frequently (i.e. other traffic) or remain fairly static (such as static things like fixes, navaids, airports).

Obviously, we would need to come up with a clever scheme to handle labeling such that labels may refer to both, static and dynamic features.
Obviously, labels themselves would then need to be put int their own canvas group, which would be marked as "dynamic" - so that they can be dynamically repositioned (using PAL or some other algorithm).

In addition, it might be worth looking into redrawing the texture not only based on listener notifications, but possibly based on a configurable frequency instead - i.e. in many cases, it should suffice to update a texture at 2-5 hz, and not at frame rate. We could support two updating modes: "realtime" (based on listeners) - and timer-based.

In turn, that would also make it possible to use "idle" time for other tasks when the Canvas update() method is invoked, i.e. housekeeping stuff that shouldn't be done when textures are updated.

Supporting a native "path" syntax that would result in less properties being written to the tree, sounds definitely like a good idea to address the sheer amount of data that we are currently writing. This would be particularly useful for complex vector data with a huge number of vertices, i.e. taxiways and other scenery info - which should also come in handy for future shapefile support.

[Hooray]

Here's an updated profile using the latest code in git, showing how the total (i.e. 100%) runtime load created by the canvas is distributed JUST within the Canvas subsystem when rendering the airport selection dialog for 2 hrs (note that none of the layers were modified or zoomed during that time):



In Shiva, things look fairly balanced now:


I added a short "stress test" to test the effect zooming has and to look at what canvas functions get triggered, changing the range at 2hz - between 1-10 nm (again, looking at JUST the Canvas system):

26.7% canvas::GeoNodePair::isComplete
16.1% canvas::Map::update
15.8% canvas::Element::valueChanged
9.2% canvas::Group::update
4.6% Canvas::valueChanged
3.3% canvas::SansonFlamsteedProjection::getEarthRadius
3.2% canvas::Map::parseGeoCoord


During the zooming-stress test, the 3 most prominent shiva functions were:

50.3% shPathArrayFind
22.9% shPaintArrayFind
4.5% shProcessPathData


During dialog instantiation, it's still all the listener-"fireworks" that's causing a fair amount of load in the canvas system:

66.7% canvas::Element::valueChanged
33.3% canvas::Map::valueChanged


In other words, it might be a worthwhile test to provide a toggle property, so that listener-notifications can be explicitly disabled, all data written to the tree (without interruptions), and then explicitly trigger the processing, only once.

[Hooray]

Tom has pushed a huge optimization to SG+FG, so that rendering KNUQ (with taxiways) takes less than 4 seconds now. Here are some updated profiling results:

Code: Select all

Total: 376 samples
     218  58.0%  58.0%      218  58.0% int find_child
      18   4.8%  62.8%       18   4.8% _IO_str_pbackfail
      16   4.3%  67.0%       16   4.3% run
      12   3.2%  70.2%       12   3.2% findcell
       9   2.4%  72.6%        9   2.4% free


Regarding the intepretation of these columns, see: http://google-perftools.googlecode.com/ ... ofile.html

• Number of profiling samples in this function
• Percentage of profiling samples in this function
• Percentage of profiling samples in the functions printed so far
• Number of profiling samples in this function and its callees
• Percentage of profiling samples in this function and its callees
• Function name

To enable the collection of these profiling results, build with the previously posted "Google PerfTools" patch applied, and simply set the "DEBUG" variable at the top of "map.nas" to 1, look up "KNUQ" via the airport selection dialog and then enable the taxiways layer.

The chain of events is this:

Code: Select all

#0  0x08b3dd73 in int find_child<char const*>(char const*, char const*, int, std::vector<SGSharedPtr<SGPropertyNode>, std::allocator<SGSharedPtr<SGPropertyNode> > > const&) ()
#1  0x08b445c6 in SGPropertyNode::addChild(char const*, int, bool) ()
#2  0x08819134 in f_addChild (c=0xc4200b0, me=..., argc=2, args=0xc420d14)
    at /home/hooray/BUILD/flightgear/src/Scripting/nasal-props.cxx:365
#3  0x08b289c8 in setupFuncall ()
#4  0x08b2a35a in run ()
#5  0x08b2bd56 in naCall ()
#6  0x0880da93 in FGNasalSys::callMethod (this=0xc326db8, code=..., self=..., argc=4, args=0xbfffe320, locals=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:137
#7  0x0880da0a in FGNasalSys::call (this=0xc326db8, code=..., argc=4, args=0xbfffe320, locals=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:122
#8  0x0881235a in FGNasalListener::call (this=0xced7a08, which=0xccb8ca0, mode=...)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:1036
#9  0x08812425 in FGNasalListener::valueChanged (this=0xced7a08, node=0xccb8ca0)
    at /home/hooray/BUILD/flightgear/src/Scripting/NasalSys.cxx:1044
#10 0x08b3e57a in SGPropertyNode::fireValueChanged(SGPropertyNode*) ()
#11 0x08b44f5f in SGPropertyNode::set_double(double) ()
#12 0x085fde13 in copy_from_pui (object=0xcb98d60, node=0xccb8ca0) at /home/hooray/BUILD/flightgear/src/GUI/FGPUIDialog.cxx:502
#13 0x085fe7aa in FGPUIDialog::applyValues (this=0x90dcb78, objectName=0xc46ac70 "display-taxiways")
    at /home/hooray/BUILD/flightgear/src/GUI/FGPUIDialog.cxx:618
#14 0x084b0ae9 in do_dialog_apply (arg=0xcaf25c8) at /home/hooray/BUILD/flightgear/src/Main/fg_commands.cxx:1035
#15 0x08b50ec6 in SGBinding::fire() const ()


[Hooray]

After Tom's latest changes, there's now hardly any optimization potential left, all the low-hanging fruits are totally gone now:

KNUQ taxiways:

Code: Select all

Total: 143 samples
      26  18.2%  18.2%       26  18.2% _IO_str_pbackfail
      14   9.8%  28.0%       14   9.8% run
       9   6.3%  34.3%        9   6.3% malloc
       8   5.6%  39.9%        8   5.6% __pthread_mutex_lock
       8   5.6%  45.5%        8   5.6% findcell
       5   3.5%  49.0%        5   3.5% naiHash_sym
       4   2.8%  51.7%        4   2.8% __strtof_l
       4   2.8%  54.5%        4   2.8% free
       4   2.8%  57.3%        4   2.8% reap
       3   2.1%  59.4%        3   2.1% bcmp