LabVIEW Idea Exchange

Many people do not realize that memory allocated by a queue is never deallocated until the queue is destroyed or the call-chain that created the queue stops running.  This is problematic for queues that are opened at the beginning of the application and used throughout because all of the queues will always retain their maximum size, causing the application to potentially hold a lot of memory that is currently unused or seldomly used.

Consider a consumer that occassionally lags behind and the size of a queue will grow tremendously.  Then the consumer picks back up and services the elements out of the queue in a short period of time.  It is unlikely the queue will be this large again for quite some time, but unfortunately no memory will be deallocated.

I'd like a primitive that will deallocate all of that memory down to just the current number of elements in the queue.  Since the queue won't need that much memory again for a long time and the queue will auto-grow again as needed, I'd like to recover that memory now instead of waiting for the application to be restarted (which is currently the only time the queue is created.)

The alternative is to add some code to periodically force destroy the queue and have the consumer gracefully handle the error and open a new reference.  Then replicate this change for all queues.  Seems messy and puts too much responsibility on the consumer.  I'd rather just periodically call a 'deallocate queue memory' primitive on the queue reference within the producer, perhaps once every few minutes, just to be sure none of the queues are needlessly holding a large amount of memory.

I believe this will:

• Improve performance in other areas of the application because less time will be spent looking for available memory to allocate.
• Reduce the chance of Out of Memory errors because large blocks of memory will not be held [much] longer than they are needed.
• Improve the common user opinion that LabVIEW applications are memory hogs or leaky.

I realize this will hurt enqueue performance when the queue begins to grow quickly again, but this area is not a bottleneck for my application.

Thanks!

I think LabVIEW should have something like the dialog VIs that acts as a popup where the vi displays a message to the user but doesn't hang up code and wait on the user to press a button.

An example case is a state machine that has error checking built in errors out.  Instead of creating a more complex error handling scheme to display the state machine errored out and heres why then shutdown the state machine, you could instead drop this async popup in the state with the message to display the error occurred then have the state machine shutdown like normal.  This way, the user knows "the state machine shutdown for X reason" while the state machine also goes into a safe state.  

I think the async popup is easier to trace since the error message is located in that section that detected the error vs having some sort of store an error string then in the shut down case read if there is an error and if so display the error once the station is already shutdown.  Additionally, you cold see where all asnyc message blocks are via dropping one in your code then right clicking and searching for all instances.  This could streamline the process to see where the fault occurred since the async message block would be in the location of the fault itself.

I have currently built something like this that is a reentrant VI whose input is a string and a secondary VI that launches the display message VI.  It's a bit of a work around, but I can display a message to the user while my code continues to do whatever it needs to.  

I'm working on a high-performance application where every bit of time counts.

LabVIEW's parallel execution helps but we are having to write individual functions in C so we can try out the AVX instructions available on modern processors.

LabVIEW recently used SSE2 so I guess the compiler supports this (well, LLVM certainly does). It would be good to have an advanced option to enable more recent updates (AVX+) to avoid going to C!

Over the years I have run into situations where I have to monitor files accessed by another application from within my LabVIEW application (Example: monitoring the standard_out/standard_error files from an app launched with the system exec).

Currently the only way to do that is to use polling. 

I would love for LabVIEW to have built in events for file monitoring so polling would no longer be required.

For instance, the following events would be very useful:

1. File Opened
2. File Closed
3. File Change  (I really want this one if nothing else)
4. File Created
5. File Deleted 
6. more...

Below is an example as to how it might look like.

As LabVIEW evolves more and more, the compiler takes over an awful lot of code optimisation for us.  This leads us to situations where relatively large and important pieces of code can be evaluated at compile time and constant folded which can greatly aid execution speed.  This is good.

Constant folding can be a great aid when programming but at the moment, it's usage is a bit "hit and miss" due to the opaqueness of the process.  We already have constant folding highlighting, which really helps things (even if the feedback is sometimes very hard to understand).  But this doesn't always give us enough feedback.

What I would like is the option to declare a portion of code as "Requires constant folding" (like a "Precompile" structure).  In this way, I can, as a programmer, designate some code which is meant to be evaluated at compile time.  If the compiler is unable to constant fold this code, then the VI should be broken.  My motivations are three-fold.

1. Sometimes we want to specifically make use of the constant folding capabilities of the compiler, but a small change can result in the code no longer being constant folded.  I would like explicit feedback when code I want constant folded is not constant foldable.
2. I have no idea whether code complexity has an effect on the ability to constant fold.  Other compiler optimisations (Like unbundle-unbundle inplaceness) are dependent on code complexity.  Explicit declaration is not code complexity dependent.
3. When looking at FPGA designs, the ability to perform constant folding of data otherwise requiring resources or affecting performance is very powerful.  In such a "Constant folding" code, we could also allow mathematical functions to be used which are otherwise not supported on the target (max/min of an array in a timed loop for example), or creating default data for an array (to be used as Block RAM) based on an existing equation where constants are defined as DBL.

One example of FPGA code is automatic latency balancing of several parameter pathways into a process where the code accepts abstract parameter objects whose latency is queried via a dynamic dispatch VI which simply returns a constant.  I use dependency injection to tell the sub-VIs which communication pathways they are being given and they can then query the latency and do some static timing calculations for the delays required on different pathways.  Tests have shown that this is constant folded and that it is thus possible to write very robust FPGA code which auto-adjusts request indices for parameters in multiplexed code.  At the moment, things seem to work but the ability to specifically designate such code as being constant folded would be welcome to make sure I don't accidentally produce a version which doesn't actually return a constant (and my compiles fail, I get timing errors, or just over-use resources)....  In the code below, all of the code circled in blue is constant-folded when compiling the FPGA code.  In the sub-VIs I have to do some awkward calculations because certain functioanlity is not available on FPGA.  By defining this code as requiring explicit constant folding, I could theoretically utilise the full palette of LV functions and also be guaranteed a compile error (LabVIEW error, not Xilinx) if the code thus designated can not be constant folded.

So in a way, it's similar to the In place element structure which, when all goes well, should not be needed but there are cases (I've run into some myself) where either small changes in code can make the desired operation impossible or where the code complexity can cause the optimisation to not be performed.  As such, it is still required at times to explicitly designate some code paths as being In-Place.  I would like to have the same functionality for "Constant folding".

The number of parallel Instance is currently capped at 64, independent of hardware. This limit should be raised.

First Reason: Since even 64 bit Windows 7 supports up to 256 cores, it would be reasonable to raise that limit to 256.

(Even the next version of windows mobile (8) will support 64 cores. (Mobile! On a Phone! 🐵. Obviously the upcoming hardware is fast moving in that direction.)

Second Rason: Sometimes it is useful to generate many instances, even if we have fewer cores available, for example maintain individual data in a large number of identical reentrant subVIs. (Such an usage example where we want many instances even on a single core machine can be found here)

Idea: Raise the max number of parallel Instances of a parallel FOR loop to 256.