02-28-2019 08:01 AM
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.
Solved! Go to Solution.
02-28-2019 11:44 PM - edited 02-28-2019 11:45 PM
What version of Vision Acquisition and/or Vision are you using? I believe this performance bottleneck was fixed in a recent version.
03-01-2019 12:09 AM
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.
03-06-2019 08:02 AM
I'm using LabVIEW May 2017 for all modules.
03-06-2019 08:08 AM
@BlueCheese,
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.
03-06-2019 10:01 AM
Hi,
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.
07-17-2019 10:10 AM
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:
07-22-2019 12:37 AM
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.
07-26-2019 10:32 AM
I'm not sure, but typically most NI software updates at least twice a year.
09-23-2019 08:33 AM
Can you post to here when this gets fixed?
Also, what do I update, the IMAQ device drivers, LabVIEW, or both? I'm currently on LabVIEW 2019.