Leaderboard

Right, VI Analyzer Toolkit 2016 was the first version to officially support 64-bit LabVIEW. For unofficial support in previous versions, we have this resource: https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/Using-the-VI-Analyzer-Toolkit-with-64-bit-LabVIEW/ta-p/3494395

Yes, it's a LabVIEW Toolkit, which means you have to install it separately for each LabVIEW you have. Here's the download page where you can get whichever version (and bitness) toolkit installer(s) you need: https://www.ni.com/en-us/support/downloads/software-products/download.labview-vi-analyzer-toolkit.html

A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it. AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. The priority queuing only becomes a part of the complexity computations if "priority" were a required input and you had to send some messages at a non-normal priority. Because you can use both frameworks entirely without ever using priority, it isn't part of the computation. It is an option that you can choose to exercise in your code or not. "If you buy it, you pay for it" features don't add complexity. "Comes with the territory" features add complexity. The requirement to create a class per message: that is complexity of the AF. The ability to send high-priority messages is not.

That is a weird, though undeniably literal, interpretation of the words priority queue. You must get into a lot of arguements at the supermarket checkout.

Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority".