From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-22-2024 11:42 AM
As a very general comment, please don't attach code as snippets when including called subVIs, because a lot of functionality is stripped out (e.g. terminal assignments, execution settings, etc. etc.).
Please take your toplevel VI and do a "save for previous" (2020 or below) and you'll get a new folder containing all relevant VIs (incl. dependencies) and as a bonus, they'll be in a version many more of us can open..
Zip it up and attach. Thanks! (... and if you do, I'll even have a look at it!)
03-22-2024 02:41 PM
@Quiztus2 wrote:
I experience a huge performance boost with this version of the fgv.
I am 90% sure this comes from switching from 3D to 1D.
I don't know DVR, but sound interesting.
One possible issue, not sure how smart the compiler is. Run your wires through for all the cases, do not use "Use Default if unwired". Sometimes the compiler is not sure if the buffer will change because now you have an unwired case. Because of that, it may make a copy somewhere which would slow down your FGV.
03-22-2024 04:58 PM
I wired all tunnels
I'll give DVR also a try
03-22-2024 07:00 PM - edited 03-22-2024 07:02 PM
The replacement using DVR needs < 1 ms in contrast to 40 ms value based.
The reading and creation of the array values again from DVR is slower than value based.
03-23-2024 03:12 AM
I think, part of your benchmark also included penalties for displaying arrays on the FP.
Just as suggestion - do it like this, this should improve execution time a little bit:
03-25-2024 10:44 AM
@Quiztus2 wrote:
The replacement using DVR needs < 1 ms in contrast to 40 ms value based.
The reading and creation of the array values again from DVR is slower than value based.
What happens if you parallellize the DVR read loop?
03-25-2024 01:30 PM
Parallel recreation of native array from DVR is slower than sequential.
For me important is, that my critical usecases:
are significantly faster using DVR. I assume here that the DVR creation from an array doesn't take significant time.
03-25-2024 01:58 PM
@Quiztus2 wrote:
I assume here that the DVR creation from an array doesn't take significant time.
The DVR method is still the fastest in my quick look at it, although I think the test should be modified like below to include DVR Creation. (Even with the mod, DVR is the fastest.)
The reason the FGV Replace (NON_DVR) is so slow, it appears LabVIEW is making multiple buffer allocations with that method. If you look at the "Profile Buffer Allocations" Tool you will see lots of buffer copies of the data. I believe that is why it is much slower.
03-25-2024 02:38 PM
Some quick mods on my computer and DVR case is now slower. VI is attached, below are the mods.
The region below in the sequence structure is not needed; it was only to initialize your values to 8888 so the equals works. You can keep if desired.
No need to reshape the array
For my test I included the DVR creation, like in my earlier reply.
03-26-2024 03:57 AM
I like the idea to use reshape instead of initing the array in the "reinitialize" case.
I also like to use rowise replacement instead of reshaping 🙂 very nice.
Do you also have a good idea on the pixel extraction along all images?
Since the difference their is still big.