Leaderboard

Like you we have been experiencing this slowdown for years as we routinely have project using classes with 5k or more VIs. In respect to "fabric" comment about refactoring/restructuring your code, this may help but it is a sad reality when you have to dump a perfectly valid architecture for a another one simply because the LabVIEW IDE make it unusable. With 9K VIs I shudder thinking how long it will take applying a typedef changes given that in our framework this sometime can take a couple of minutes. Regarding solutions: The single most bang for the buck that we have found is to NOT use the project. This help a lot. Just open the lvclass you need to work on in memory. Even if you where to open all your classes one by one, as long as you are not using a project the IDE will be significantly faster (compared to have the same classes in a project). By the way, I got fabric's Idea to 103 now.

You appear to be able to use a global variable in the same way in a class, it doesn't create directly under the class but you can add it and set the scope to private.

> What's inside, borscht, kimchi or Chicago hot dogs? Inside? LabVIEW, of course. This is the pot we boil it in so it fits on an RT target. The left over broth makes excellent documentation.

Alex, you can guess my advice: do away with the over-complexity of dynamic launching and the like. But ignoring that... Whatever way you do this, it is better to think of the consumer making the data pipeline and getting that reference to the producer, rather than the other way round. The consumer is dependent on the queue, the producer is not. If I were designing something like this with my messaging design shown above, the producer would send it's data to an "ObserverSet", which by default is empty (data sent nowhere). The consumer would create a "messenger" (queue) and send it to the producer in a "Hey, send me the data!" message (alternately, the higher-level part of the program that creates both consumer and producer would create the queue and the message). The producer would add the provided messenger to the ObserverSet, allowing data piping to commence. In the below example, the consumer code registers it's own queue with the producer and is piped 100 data points. The Actor Framework is rather advanced. You might want to look at "LapDog" though, as it is a much simpler application of LVOOP that one can "get" more easily (I am surprised AQ thinks the Actor Framework is simpler). -- James