VI Profiler shows high queue node times: is wire buffering the cause?

No, there is no documented threshold that triggers internal wire buffering for queue nodes in LabVIEW. The high CPU time observed in the VI Profiler is likely caused by data copying overhead, synchronization contention, or profiler instrumentation itself, rather than a hidden, tunable buffer limit.

While LabVIEW's dataflow engine inherently buffers data on wires when producers outpace consumers, the logic governing buffer sizing and activation is managed internally by the LabVIEW runtime memory manager. There are no VI settings, INI tokens, or runtime options that allow users to configure or override this behavior.

Why Queue Node Times Are High

When Enqueue and Dequeue nodes dominate the profiler, the bottleneck usually stems from one of the following:

• Data Copying: If you are passing large arrays or clusters by value, LabVIEW must perform a deep copy for every enqueue and dequeue operation. This CPU cost scales with data size.
• Synchronization Contention: Queues use synchronization primitives (mutexes/semaphores). If the producer and consumer are fighting for access, the threads will spend time waiting for the lock, which registers as node time.
• Profiler Overhead: The VI Profiler adds overhead to intercept node execution. In high-frequency loops, the time taken to "measure" the node can sometimes exceed the execution time of the queue operation itself.

Target and Version Differences

The behavior of these nodes varies across environments and versions significantly:

Aspect	Impact on Queue Timing
Version (2020 vs 2023)	Internal optimizations improved memory reuse and reduced contention, but no buffering thresholds were introduced.
Windows Target	Uses virtual memory and non-deterministic scheduling; profiler time includes time spent in profiler-specific data structures.
Real-Time (RT)	Uses deterministic schedulers and fixed-size memory pools. Timing is more predictable but sensitive to priority inheritance.

How to Verify the Root Cause

To determine if the bottleneck is genuine or an artifact, follow these steps:

1. Isolate Overhead: Wrap your Enqueue and Dequeue nodes with Tick Count (ms) or Get Time functions and log the results to a file. Compare these values to the VI Profiler results.
2. Test Payload Size: Replace your complex cluster with a simple integer. If the queue node time drops significantly, the issue is data copying (memory).
3. Check for Contention: Introduce a small Wait (ms) in the consumer. If the queue time decreases, the threads were likely colliding on synchronization primitives.

Note: If you are passing large data, consider using Data Value References (DVRs) or Channel Wires (introduced in LabVIEW 2016) to minimize deep copy operations.