Machine Vision

Showing results for 
Search instead for 
Did you mean: 

Why does "IMAQ Create" time increase non-linearly with increasing buffers?

Why does "IMAQ Create" time increase non-linearly with increasing buffers?  Is there any way to improve this allocation speed?  


I would ultimately like to do 100x100 images at 10 kHz with 100K frames on a PCIe1433, but the allocation time for the buffers is ridiculously long. I am using LabVIEW 64bit and have 32GB of RAM. The RAM is less that 25% used.


I can use competitive hardware/software that can do this almost instantaneously right out of the box.







See the attached code and test results for details.

0 Kudos
Message 1 of 9

What version of Vision Acquisition and/or Vision are you using? I believe this performance bottleneck was fixed in a recent version.

0 Kudos
Message 2 of 9

Just did a quick check, and this was supposed to be addressed in 18.0 (internal CAR 569446). Reading through the notes, I'm not sure if the fixes specifically help the Create/Destroy pattern you are benchmarking or speed up accessing images internally when part of a massive list.


I did notice running an 18.0 stack that I had a 2x improvement on your test code when I removed the parallelism from your for loops. There is clearly some internal lock contention for some shared data structures on Create/Destroy, and so trying to multi-thread it only causes more overhead.

0 Kudos
Message 3 of 9

I'm using LabVIEW May 2017 for all modules.

0 Kudos
Message 4 of 9



That's strange you see an improvement when removing the parallelism.  I see the exact opposite result.  Parallelism decreases time by 2-3x on my system.


The create/destroy pattern is merely to benchmark the allocation/deallocation and so that I don't have to post Proprietary code.  Obviously in my end  application, I allocate, do a bunch of stuff, then deallocate when I'm done.


Don't lose focus.  I'm asking why the allocation time is nonlinear and why it takes so long.


As a side note, we've recently switched to another vendor's frame grabber and software that can perform this equivalent action nearly instantaneously.




0 Kudos
Message 5 of 9



I reproduced the issue you are seeing on a system with 18.5 Vision libraries. The improvements I was mentioning for the large-number-of-buffers usage went into the 18.0 version. Because there were some changes made in this regard, it is possible some nuances of the performance could be different (such as regard to the parallelism helping). In any case, the core problem of create/destroy having non-linear growth remains. I'd still suggest upgrading your drivers to the latest Vision Acquisition version as it will upgrade these underlying libraries as well, where some improvements have been made.


The underlying cause of the performance issue you are seeing is that creating an image interacts with both data structures in Vision's liraries as well as LabVIEW itself (since images are refnums in LabVIEW). While the change I mentioned helped the Vision side of things, it seems that in LV 2010, a change was introduced to make creating new refnums use a linear search through the table of created refnums, instead of the previous binary search. This causes the time to increase with every item added. CAR 730596 has been filed for this issue.

0 Kudos
Message 6 of 9

Just to give you a quick update:


The CAR mentioned above has been fixed and should appear in the next software update release of Vision or any IMAQ driver packages.


You can see a significant improvement from the original (blue) to the new gray line:

IMAQ Create Time.png

Message 7 of 9

Any idea when the update to vision should be available?


I am having the same problem. In my case I did experience a slowdown with loop parallelism enabled.

0 Kudos
Message 8 of 9

I'm not sure, but typically most NI software updates at least twice a year.

0 Kudos
Message 9 of 9