Retrieving data from DataBlock bottleneck

[Kaine van Gemert]

Hi!

I'm writing a custom deformer using the C++ API (I hope it's okay to post that here!) that operates on many individual meshes. I've found that one of my biggest bottlenecks is simply reading the data from my inputs.

As an example, if I create a deformer that does nothing but get the value of a single plug:

MStatus MyDeformer::deform(MDataBlock& data, MItGeometry& itGeo,

const MMatrix& localToWorldMatrix, unsigned int geomIndex)

{

MStatus status;

        MMatrix inputMatrix = data.inputValue(aInputMatrix).asMatrix();

        return MS::kSuccess;
}

and then in my Maya scene, if I plug 20 meshes into this deformer, or plug 20 meshes into 20 of these deformers (the performance seems to be equivalent) and constantly change the input matrix (locators world matrix in my tests) I get an increase in CPU usage

of around 19% compared to if these deformers were not present.

To test, I created 20 DistanceDimension nodes, which at the very least have to read the two inputs from the data block for the start and end positions, do a calculation and finally do some drawing in the viewport for the display, and I only get an increase of 6%, compared to my 19%! :(

(I've also tried changing the matrix attribute to a double3 in case getting matrices were just particularly slow)

Is there a way to optimize this? How do these in-built nodes read the data so efficiently? My node has several attributes that is has to get and just reading these inputs is destroying my CPU..

Thanks!

Kaine

[kevco...@gmail.com]

Hi, I don't necessarily agree with the idea that an increase in cpu usage dictates a performance increase in your node. Low cpu usage doesn't mean your node or code is slow. cpu usage is not a very good way to gauge the performance. Even frame rates would be better, but the profiler would be ideal.

are you using parallel evaluation?

I would think the hit you're taking is not in retrieving an MMatrix, but rather in the MItGeometry iterator being created for you.

You also don't have to use the deform() method, and can do your deformation within the compute.

You're also using the inputValue, which could also cause everything upstream to be recomputed. I think it's pretty common to use outputValue from within the deform method.

goodluck!

[Justin Israel]

On Thu, 1 Sep 2016, 6:00 PM <kevco...@gmail.com> wrote:

Hi, I don't necessarily agree with the idea that an increase in cpu usage dictates a performance increase in your node. Low cpu usage doesn't mean your node or code is slow.  cpu usage is not a very good way to gauge the performance.  Even frame rates would be better, but the profiler would be ideal.

Maybe I misunderstood, since I don't write deformers... But I read the original description in the opposite way. I read it as a custom node that is doing almost nothing for its logic using way more cpu than a builtin node doing alot more logic with less cpu. 

But the rest of this answer looks to be addressing the potential cause of excessive cpu utilization  

are you using parallel evaluation?

I would think the hit you're taking is not in retrieving an MMatrix, but rather in the MItGeometry iterator being created for you.

You also don't have to use the deform() method, and can do your deformation within the compute.

You're also using the inputValue, which could also cause everything upstream to be recomputed.  I think it's pretty common to use outputValue from within the deform method.

goodluck!

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/322f1b59-7bb6-4e67-b76c-2c4c16f69295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kaine van Gemert]

Hey!

I know that CPU usage is a poor statistic, however I would have thought that my node which does nothing except read a value would have less of an impact than a node that is doing actual computations. CPU usage when using my node jumps up to a higher usage than it does when a full production rig is animating. I'll see if I can do some profiling, maybe compare it to a blank utility node that reads the same value..

I switched over the to the outputValue ealier to test but then my node stopped updating, despite the fact the input was changing. I guess this is because the outputValue method doesn't mark the plug as clean because it doesn't perform an evaluation? However if I manually set it to clean, since the graph hasn't evaluated, that could produce incorrect results or am I misunderstanding something? I only just started programming in the API so still have a ton to learn :)

Cheers,

Kaine

[33th...@gmail.com]

Ah, I see. Okay, I read that wrong :)

What's the scheduling type on your node? I believe you still need to tell a node to execute in parallel eval by setting its scheduling type.

Are you compiling in debug? That will be slower too.

But seriously, those geometry iterations are expensive to create.

[33th...@gmail.com]

if you can do your deformation inside the compute, using a function set instead I think it will be a bit faster. But it really depends on if the methods you need are in the function set. since some methods are unique to the iterators. with a function set you can also set all the points at once, and not just one by one.