OK, I feel like I finally understand what is going on here, and it is a bit of a wierd one. It has very little to do with the subVI except that the subVI reorganizes the code and provokes this.
The outer loop is running quite fast and the case structure's contents run very rarely and have little impact on the execution speed. The problem is that the contents of the case statement contain the property node to read the history of the chart. In the fast code, the loop runs in the Std Execution system and occasionally, inside the case statement, it needs to transition the execution to the UI thread to get the history value. It may stay in the UI thread awhile, or it may immediately switch back. Either way, there are just a few of these transitions. Each of them adds overhead, but compared to the work being done, the overhead is pretty small and acceptable. In the code that runs about 8x slower, the UI-ness of reading the history is leaking out to the case statement itself. The outer loop starts running in Std, then to execute the case structure, including the empty diagram, it transitions to the UI execution system. After the loop it could stay in the UI for awhile, but you also have the asynchronous Wait MS Multiple and that tends to push execution back to the original thread. With both of these in the same loop, we have 750 times more execution system swaps than in the original code. If the code in the loop did more, it would probably shrink back into the noise, but at the moment the loop runs fast enough that this extra cost means an 8x loop rate penalty. Morals? This is one of those unfortunate times when the static analysis LV does on the diagram fails us and LV guesses wrong. It assumes that since some of the code needs the UI thread, you are better off moving most of it and amortizing the cost. Unfortunately, something else isn't playing along and we end up being penalized. The good news is that this alignment of the stars doesn't happen very often, and it shouldn't be something you really have to worry about. And this is something we are constantly tweaking to get the best performance in the typical usage. The thing that provokes this is mixing UI and data computation in the same loop. In particular, the chart's history buffer is being used as the circular buffer for the analysis. If the circular buffer was shift-reg style, the whole diagram would be running in the same execution system and it would be still faster than even the fast loop here. So I guess the thing to take away is that using the chart as a quick and dirty circular buffer is sometimes too quick and too dirty and can gum up the works. Greg McKaskle
