Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Overhead impact of numerous level of class inheritance

To be fair, you're no longer addressing the overhead of a single DD call, which is what I was talking about. You're now talking about a chain of nested DD calls. Or close to it ... CPN is not fully DD, but it does have some of that 4x overhead.

My original statement stands -- for any given DD call, the depth of inheritance does not matter.

0 Kudos
Message 11 of 14
(989 Views)

AristosQueue wrote:

We *think* they're all fixed with the upcoming LV 2016. You should be able to put a parent class in one PPL and a child class in a separate PPL and replace the parent PPL with a later version on a deployed system without recompiling the child PPL, provided you don't change basic type signatures. Private-behind-the-scenes details including the parent class' private data and the internal implementation of VIs should not cause a break.

That's exciting.

0 Kudos
Message 12 of 14
(989 Views)

Terminology is perhaps being interpreted differently here.

Me: DD Call overhead = any overhead associated with the execution of a given DD class method (Including CPN)

AQ: DD Call overhead = overhead associated with a single VTable lookup (to use C++ parlance)

I would suggest that (at the risk of creating a completely redundant phrasing like "PIN number")

DD Dispatch = overhead associated with a single VTable lookup

DD Call = overhead associated with the execution of a given DD class method (including CPN)

However we want to name it, the overhead of a DD VI on a BD (code execution time vs VI overhead trime) is very much a function of the number of CPNs performed within and is not inherently independent of hierarchy depth (unless CPN is of course unused).

0 Kudos
Message 13 of 14
(989 Views)

Using your definition, I cannot say anything meaningful about the performance of the node because that's equivalent to one DD VI that calls another DD VI inside itself that calls another DD VI, etc. The internals of the function are whatever the internals of the function are. If you write your routine to do lots of internal function calls then it takes longer. And just because you have a depth of 300 ancestors doesn't mean that you have 300 levels of hierarchy to crawl through. Many, possibly even most, dynamic dispatch functions do not have any CPN calls on their diagram, and those that do are not necessarily crawling through every level. There's zero relationship between the DD call and what the VI chooses to do in its diagram.

It's exactly like saying "The call overhead of a static dispatch subVI gets longer when you have a deeper VI hieararchy." True, but completely unhelpful when trying to evaluate the overhead of the call itself.

0 Kudos
Message 14 of 14
(989 Views)