Unflatten from String to IMAQ image- Execution duration increases over time in EXE

[MalvikaBadri]

In one of our projects developed using Actor Framework, we noticed that the execution time of one of the loops increased after a while, and the application memory also kept building on gradually.

Detailed Description:

1) We have an event handler loop with an enqueue node in its timeout case (Flattened image string is received from TCP and Enqueued to internal Queue) and a second dequeue loop in one of our VIs (Actor Core). When we stress run our application for a long time, after around 2 hours, we find that the 2nd loop execution time increases (say from 40ms to 100ms). This also increases the application’s memory consumption as the Dequeue rate is slower than the enqueue rate. (Refer Attached Image: Loops.png)

2) The issue is seen only in the EXE and not in the source code

3) The second loop has a Parse VI with "match pattern" and "unflatten string to IMAQ image" nodes. From our trials, we see that the Unflatten node takes longer time to execute after a few hours. (Refer Attached Image: Parse VI.png)

4) The flattened string size is 32MB which will get unflattened to a IMAQ image of size 4K x 4K U16. 

What we have tried so far:

1) Replaced the second loop with a timed loop

2) Setting the Parse VI to subroutine and time critical (highest) priority

3) Inlining the Parse VI

4) Using Request Deallocation node inside the Parse VI

5) Used Desktop Execution Trace Toolkit to look out for reference or memory leaks- None found. 

6) Created a separate prototype VI to check if the unflatten to IMAQ image was taking longer after a while. But the results were pretty stable and did not increase in value over time.

The above trials did not help us sort the issue out. Is this a known issue with the unflatten node or is there anything else that we could try which might fix the issue? 

[wiebe@CARYA]

Why is the N of the for loop wired, and not (only) the P? Wouldn't that mean that only the first 50 images are processed, and the rest is never processed nor closed?

This might explain the problems in the executable. If the producer runs faster (because it doesn't have debugging code in the executable), it might produce 50 items faster or more often. 

Before trusting DETT, I'd make sure it understands IMAQ images. They are a bit odd, and might not be considered by DETT at all.

I'd make sure leaking memory isn't the issue. Performance Monitor is a reasonably reliably way to spot memory leaking.

Without code, this is even harder for us that it is for you...

[wiebe@CARYA]

I'd also replace the images with strings.

This won't do anything, but might narrow down the problem...

If it is the unflattening of images, I'd try to allocate images myself, and unflatten the string to a 2D array and put that in the image. Just to get rid of the unflatten to image.

In general, replace or remove all uncertainties until it's narrowed down to the problem. Then work out a solution if it's not fixed.