David Staab wrote: Processing any message with a variable-sized array or string will blow up your determinism. So will casting to a different Message on every call of Do.vi(). |
Boldface portion is incorrect, but it isn't David's fault. There's some serious bad information about classes on RT in the community noosphere.
David Staab wrote: When the object entering/leaving a terminal on a VI changes shape (by dispatching to a different class of object), there is a memory allocation. That's why you see a longer execution time on the first run against a child object. The MHL processes a different object with almost every message, so this allocation will happen almost every time. |
Again incorrect.
This is a rumor that got started somewhere and I've been trying to kill it ever since my NIWeek 2012 presentation. The rumor comes from me being imprecise with words in a couple of early posts and from some really flawed benchmarks that usually reliable users posted. I lacked the RT experience to counter the rumor until 2012. The following overrides anything you've heard elsewhere, even if I said it. It is true as far back as LabVIEW 2009, the version where objects on RT were first introduced. I've had multiple RT R&D folks verify the code by visual inspection and the performance by experimental testing.
Dynamic dispatching is deterministic, even if the object is a different class from one iteration to the next. It does not matter whether the class has an override of the method or not. There is no data copy of the object at the point of dynamic dispatch. Dynamic dispatching is like the ? terminal of a case structure: there's no penalty for using the case structure itself. You do have to make sure that all the frames of the case structure take the same amount of time to execute. In the same way, if all of your overrides have the same time to execute then dynamic dispatching does not add any jitter to the determinism. In general, consider the issues posed by a case structure for determinism and apply the same concerns when working with dynamic dispatching.
The child class objects are all the same shape as the parent class objects. That's why dynamic dispatching works. All the fields are laid out in exactly the same places in the child that they are in the parent, so the exact same compiled code can work on both.
In any case, dynamic dispatching DOES NOT cause a copy of the dispatching object. Period. Wire forking and modifying the object MAY (but not will) cause copying, just like on any other piece of data.
All of the preceeding is true regardless of the depth of the inheritance tree, regardless of the breadth of the inheritance tree, regardless of the existance or non-existence of an override at every level of the tree, and regardless of whether an override uses the Call Parent Node.
Please update your mental databases.
None of that applies to message handling since every message has a different time to handle, so the Do.vi call will take a different amount of time each call, and there might not be any message waiting in the queue, which would make the loop go to sleep. That's why not to use a Timed Loop, even if it were available on Mac.
