Globals in and of themselves are not the problem.
You are correct.
I don't think anyone would want to argue that point.
I did start to do a benchmark using a large data set. The global failed so severly, I didn't continue.
This code took >5000 ms to complete.
The same with an Action Engine was below resolution (returning 0 or 1 ms).
Benchmarking was done in 7.1. Code is attached in the zip file.
Globals provide memory space for writing reading data. Should you drop two or globals down that do writes or reads or write-read or read-write question is what the order performed.
The use of a sequence structure on your block diagram gives exclusive processing to the sequence structure (no other Block Diagram code run till that sequence structure completes (try it and see). Put more and more Globals in sequence structure and your code get slower and waste processing defeating the concept of data dependancy.
Well maybe Global aren't bad but sequence structure to handle globals, well there's a multitask multithread... speed hit.
@richjoh: I think you completely miss the point. The sequence is just for isolating the 'Index Array' section of code to do some benchmarking. This would never be code of an app, it's just benchmarking (see this of Damien's Developments or this community nugget by tst). If you are still not convinced, please use the code attached on my previous post and notice that the code for the AE is identically using the sequence structure, but more than 1000x times faster.
Now I'd like to scientifically discuss the results of this benchmark, which in fact did surprise my by the huge (magnitudes) the AE did win against the global.
Concerning my benchmark, I reasonend that the one rule to follow when asking for good performance is to keep data on the wire.
One might ask, why the global is put outside the foor loop. But this is intentional for two reasons:
A second objection against the benchmarking code would be, that I might get the same bad result if the AE would return the full data set and the indexing would take place outside the AE (a simple data access FGV with get/set). But this would imply to force a bad coding practice! AEs allow for encapsulation (a concept known in OOP with strict accessors like in LVOOP).
Doing some more reasoning about this, the codes output would change in the situation where some code would write at the global in the meantime. Yes, we all know this is the very bad situation of a race-condition. But this disallows any compiler optimization similar to 'constant folding'.
So in fact, every loop iteration, using a global I need a full copy of the approximately 4MB data that is stored in the global (so in the meantime, any other process can use the global safely). So I need to move around 4GB of data. Using an AE, the contrary happens, the subVI boundary prevents any code to access the same data (it's on the wire), so the compiler can optimize and reuse the buffer. In this situation, only 4KB need to be allocated (would mean a theoretical performance improvement of E+6).
So to summarize, to mechanisms work in favour of the AE:
This all can be condensed into points:
I leave the LVOOP benchmark as a homework, but here is my predictions:
Additional penalties might happen when there is other data (like a string) on the objects private data cluster forcing a buffer reallocation. The general OOP-penalty of overhead due to ynamic dispatching is absolutely neglectible.
In basic situations (like the benchmark code), we will find a very similar performance as with the AE, as all data is kept on one wire. Using LVOOP in a large scale app, this won't be true as in all the code the class wire is running through, we need to eliminated all branching that kills performance. In an AE, the data wire is encapsulated as well, so only the AE must be improved, tested and only the AE coder must know about performance strategies. The very last point (only the AE coder must know about performance implications) would push any good LV architect on using AEs for large data sets only.
Oh I forgot to mention who my response is directed too, SteveChandler not F Schubert.
Schubert look at the initial post from SteveChandler. I only read the first line of your resonse and see myself addressed.... my post if for SteveChandler code only, I only glanced at your code in the pic. I could comment about your code too, but this is not the discussion.
And as I read more of your response Schubert, I see we are in total agreement, no need to say more.... this is SteveChandler code discussion.
If you move the global outside the for loop you will get much better numbers. Almost comparible to the FG. Edit: Still waiting with duct tape for Ben or Christian
Uhhh? did you say faster, what line impies that... cus I read this from the link you provide.
appear to me not better maybe specifically.... Try something whenever possible, write code using your described globals methods, see if it runs faster, multithreads, multiprocess faster and your code debugs faster.