[Bf-committers] I need help reducing RNA lookups for fcurves

[Joshua Leung]

Hi,

See replies below.

On Tue, Dec 6, 2011 at 8:12 PM, Mitchell Stokes <mogurijin at gmail.com> wrote:
> Hello devs,
>
> I was doing some profiling on an animation stress test scene in the
> BGE. I found that around 20% (18.8% in my last run) of the time was
> spent on looking up RNA paths (RNA_path_resolve). The way fcurves are
> currently executed, they each store a path and an index for array
> properties like location and rotation. Each fcurve is executed
> separately from from the others so each for each fcurve there is a
> call to RNA_path_resolve. This means 3 calls for one bone for position
> and 4 calls for one bone for rotation (using quats). So, for one bone,
> this are 7 calls that can be reduced to 2. Assuming each bone with
> fcurves has position and rotation curves, this would reduce the calls
> to RNA_path_resolve by about 71%.

While there are some inefficiencies here, for reference, how much of
the rest of the time was spent by other areas? Was this the sole
largest time sink, or is it one of the "easiest" to tackle first?

> That covers the why, but I need help with the how. Creating a version
> of animsys_write_rna_setting() that works with arrays would be easy
> enough, but I'm not sure how to handle groups of fcurves at a time. I
> know there are groups in an action, but I don't think bAction::groups
> represents all the curves in bAction::curves. Also, it seems to me
> that a curve can belong to multiple groups, and that the curves in a
> group don't necessarily all use the same RNA path. Any thoughts?

I think several things need clarification here.
- bAction.curves represents ALL of the F-Curves that action has. All
of the grouped ones appear first, in the order in which the groups
they belong to exist. These are then followed by the ungrouped curves
(which these days usually consist of those F-Curves which got created
via inserting keys directly on buttons instead of via a Keying Set).

- A single F-Curve can only ever belong to one group at a time. If you
find a file where this is not the case, I'm afraid that it would've
been stuck in an infinite loop on file load.

- Indeed, there is absolutely no guarantee that curves in a single
path belong to the same RNA Path. Although we currently by default end
up with all the F-Curves for a single bone in a single group (and the
F-Curves for other bones in other groups respectively), it could be
equally possible (if a user created their own hand-crafted Keying
Sets) that they have a situation where they've got F-Curves from
multiple bones in the same group. Even in the first case here, you'd
still have some location and some rotation (in the typical case) per
group.


And one last thing: be very careful whenever you start trying to deal
with caches. Outdated or too frequently refreshing caches are a very
common problem, and one that can we should be all to aware of.