LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
rbj

Create Class output for Actor Framework Accessors

I've been working on a project for the last few months using the Actor Framework, very happy with it and would definitely recommend it to a friend.  I noticed the accessor methods for the "Caller Enqueuer" and "Self Enqueuer" have a class input but no class output.  This results in branching the class wire in most of the calls to these methods which can get a little bit ugly and I also believe results in an additional copy of the class being made in memory.  I appologize in advance if there is a good reason for these methods being implemented the way they are, or if this has already been asked.

AF Accessor Method Image.png

2 Comments
AristosQueue (NI)
NI Employee (retired)

Not having a class output is very deliberate -- it specifically PREVENTS you from serializing the calls the way you suggest in your proposed solution.

 

Such serialization only has downsides -- it prevents the LV compiler from applying any parallel optimizations to code. It creates a misleading implication that the object could be modified by calling the Read function, which leads people to make wrong assumptions about the functionality of the nodes.

 

In all of the APIs that I work on, I have been removing object outputs from functions unless:

a) the function actually modifies the object or

b) the object's private data contains a modifiable refnum.

When I observe user programming patterns, I notice that eliminating those terminals results in much cleaner and more efficient code. Others in the Actor Framework forum and elsewhere have made similar observations. Compare with the Unbundle (By Name) node. There's no "object/cluster out" terminal on it, and for much the same reason.

 

> and I also believe results in an additional copy of the class being made in memory.

 

Not in this case*. Forking wires only results in memory copies if making copies is necessary. Let the compiler worry about memory copies. It isn't perfect, but I guarantee it is smarter than any human being doing a casual analysis of the diagram, and it gets smarter with every LV version released.

 

* You can use Tools >> Profile >> Show Buffer Allocations... to see where buffers are allocated on a given diagram. Not every dot indicates that a copy is necessarily made of the data, but if there is no buffer allocated then you know a copy definitely is not made. I sometimes hesitate to show people this tool because the data requires some study to read accurately, but for a simple case of verifying your diagram shown above, it works fine.

Darren
Proven Zealot
Status changed to: Declined