QSM Memory allocation as a function of elements in the queue (LabVIEW 2011)

[Waveshredder]

I am using a QSM (queued state machine) achitecture to sequence through a set of test steps (setup, measure, log). When queuing up a large number (>100,000) elements in the queue, the Windows memory allocation to LabVIEW goes up dramatically, and the LabVIEW execution time slows as a result. This occurs even when no data is passed with a queue element (a NOOP queue state).

How does LabVIEW allocate memory to a queue when an element is added to it? I thought this was simply a list of queue elements which would require an insignificant amout of memory.

[RavensFan]

There is data associated with every queue element.  So 100,000 queue elements will take up 100,000 slices worth of data somewhere in memory.  I just don't think they have to be contiguous like they would be if you were saving a 100,000 element array.

It seems crazy to need to enqueue that many elements at once.  I assume there must be some sort of pattern to the items that you are enqueuing.  Why don't you have items gets enqueued as the state machine runs?  Each state can re-enqueue itself as need if there is some sort of repeating pattern.

[crossrulz]

This sounds a lot like an application that TestStand would be good for.

As already said, each element in the queue has to reside somewhere.  I would recommend Raven's plan of attack (have a state enqueue additional states).