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.

@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:

The idea of a 'global' (including FGV and AE) is to access it at different sections of the code.

Having it outside, I would benchmark the performance of the wire and not the global.

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:

the native protection at the subVI boundary (semaphore/mutex) against parallel data access

(and thus allowing compiler optimizations) a buffer reuse

This all can be condensed into points:

Keep data on the wire

AEs are natively keeping it on the wire

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.