hooovahh

I participated in the 2022 Q3 beta. And I see Christina mentioned preparing for the 2023 Public Beta on March 9th of 2023. Which is a bit odd since the mentioned release date of 2023 Q1 was January 2023, with the last update on the document being March 16th of 2023. I never saw a 2023 beta before it was released.

This idea was implemented. https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Same-Height-of-Unbundle-by-Name-Terminal-Local-Variable/idi-p/1298608 Opening existing code will create bends in wires where there weren't any before.

I just went to 2022Q3 64-bit about a month ago with a fairly basic program. USB cDAQ chassis with DAQmx and XNet on Windows 10. It had several classes, reentrant-ness, subpanels and data logging. I haven't seen any weirdness yet. My next step is to dive in upgrading our Linux RT remote controllers and our sequence editor, and report generation. This is a much larger project and one more likely to find issues.

Thanks, that's it. I couldn't find it because I was searching for Completed ideas, but apparently it was declined. The Type Specialized Structure was in LabVIEW 2016, and was part of my NI Week demo that year. I frantically downloaded the Mac 2016 version, extracted the installer to get the VIM that contained the structure, so I could update my presentation and demo. When it was a Macro it was an XNode behind the scenes, and even the 2017 beta used XNodes. But in the official 2017 release it was its own technology. XNodes and Classes don't work well together, and locking libraries made editing them challenging so it was necessary to be their own thing.

I do love how VIMs came to be. I'm having a real hard time finding it. But there was an idea on the Idea Exchange that there should be a function that can delay any data type, similar to the OpenG Wait which takes an error in and passes it out. Jeff K. posted on the thread saying something like "Oh yeah that is a thing, you just need to use a VIM, here is an example which uses XNodes." It blew my mind. Then in the next release of LabVIEW for the Mac, Jeff K. sneaked in a new VIM on the palette which some high up in R&D didn't know, which had the type specialized structure in it, which was also unreleased. I downloaded that version just to get the VIM and structure. I get the feeling the reason VIMs seemingly came out of nowhere, is that Jeff was pushing for it for years, and then when it was mostly stable he just put it out there to get the public's response. When everyone saw the potential that he also saw in it, R&D put efforts into getting it out there. This is just my speculation from the outside.

I made a separate thread over here for array performance testing.

OpenG made an amazing set of Array tools, many years ago. They weren't perfect but had many uses and I've recommended many times. Improvements to LabVIEW meant some of the array functions weren't well optimized. Years later I tried making a more modern Array set of tools using VIMs, giving up on Polymorphics. I posted this as a package over on VIPM.IO here. Since then I've thought about a few places where performance of my stuff could be better. Mads and I have had some discussions back and forth in this thread. But I wanted to make a separate post where others could chime in with their performance suggestions too. At the moment my Array VIMs are in LabVIEW 2018. However I think due to the potential Maps and Sets benefit, that I want to go to at least 2019. In 2020 LabVIEW added the Sorted Array subpalette with a pretty decent binary search. So for now I think LabVIEW 2020 will be what I target for the next Array VIMs package release. Any thoughts on this? I know there is a decent amount of bias in this, but Jim posted the versions of LabVIEW used on VIPM.IO and 2020 and newer covered over 75% of users. So attached is zip with a set of array testing VIs. For instance open the Remove Dups Speed VI and run it. It will run through the 6 different methods of removing duplicates from a 1D array of strings. It will then graph the different methods and do a check that they all return the same data. If you want to add your own method edit the (non-typed) enum, then duplicate a case and replace the function with your won code. It randomizes the order of the array methods used. You can also mess with the data being used. At the moment it generates 1000 unique elements, then duplicates them 5 times. If you want to enter data with none to remove, or all of a single type, or whatever then you can change the data to be used in the test. At the moment there are 8 different array speed tests to compare. Things like Delete 1D, Delete 2D, Filter 1D, Filter 1D with a Scalar, Reverse 2D, Search 1D, and the Remove Duplicates already mentioned. There might not be a single best method for a specific function. There are times one method will work better for some set of data, and then a decision needs to be made on what should go in the VIM. My main reason for making this thread is that I hope some people will know of a better way to do something. Come up with a more optimized way to do any of the OpenG array functions. After some discussion, and contribution I plan on updating the Array VIMs package and attribute those that helped. (crosspost) Edit: I just realized someone is probably yelling "Use Git" to me. I hadn't thought of that sorry, it just felt organic to continue the conversation here because it is where the topic started. 872707096_HooovahhArrayPerformanceTest.zip

SubVIs that are called as a function, and don't have the terminals change value after entering the VI, should have the terminals on the root of the diagram, not in sub diagram structures. This is because the compiler can't know if these terminals changed value from the last time they were used, and so it will read them again. If it is on the root of the diagram it reads it when it enters the VI and never needs to read it again. Same with indicators. These should be on the root of the diagram and I think the CLD takes off points if it isn't. https://forums.ni.com/t5/LabVIEW/Community-Nugget-Wired-Terminals-in-Subdiagrams-Clearing-up-the/td-p/2093252 But it is a very minor thing, I just mentioned it as something I'd change, but not something I would expect to affect memory. I worked at Magna Electronics, Magna E-Car, and I think Magna Powertrain was in there somewhere as divisions changed and were absorbed. Making validation and verification test systems for various automotive components like running boards, inverters, chargers, power control modules, and cameras. Good times until it wasn't. I knew this was related because it gave a loading warning that VIs were loaded from a new path, and the old path had Magna in it.

Those VIs are quite simple. If there is a memory leak in that simple of a VI then you need to open a support ticket with NI so it can be fixed in a patch. I see things I would change about the VIs, but nothing that should affect memory. Like the terminals should be on the root of the diagram for subVIs. (Also are you doing work for Magna? I used to work at a couple of their divisions)

Oh I totally agree here and wouldn't suggest otherwise. All I'm saying is that specifically for the Filter 1D there is two main approaches. To perform the filter in a for loop running for all elements in the Filter Array, or running a for loop running for all elements in the Array In. If one is small and the other is large one approach will easily outperform the other, even if it isn't optimized. So maybe deciding which technique could be used based on the size of the Filter Array. Additionally I like the No Duplicates input, because there are often times when I'm filtering an array of numeric indexes, and removing 0 or 1 elements from each Filter Array element can make for lots of shortcuts. I tried optimizing your sort and binary search with this, but the benefit where much since I think the majority of the time is spent sorting the array for large arrays, and then the actual binary search is very quick. Similarly I've added the Array Is Sorted input to my Remove Duplicates VIMs. If you are removing duplicates from an array that has already been sorted there are shortcuts that can be taken that save lots of time. I think the Remove Duplicates I have is very slight improvement to the OpenG method, and I'll stick with what I have at the moment. However your sort, then work does give me an idea I'll test when I get time.

That is pretty fast. I have noticed that on smaller arrays some of the other methods work better. Somewhere between 100 and 1000 elements the first Revision works better, then Revision 2. And the Hooovahh method with No Duplicates is faster then Revision 2 at at least 500 elements. I've also seen that with a smaller number of items to filter, other methods work better then Revision 2. Even OpenG beats it when there are many items, but only a few to filter. In most cases when I'm filtering an array, I have a relatively large set of data, and a small-ish array of things to remove. I'm finding it difficult to know what method is best for the most common use cases. Is it worth wasting some processing time reading the array sizes, and then picking the algorithm that works best for that size? The problem I see with this is various compiler optimizations may take place, making some methods faster or slower, with later releases of LabVIEW. Since my method basically is for all Items to Filter, and your method is for all Array In, I could say if the Items to Filter is 10 or less run the Hooovahh method. If it is greater then 10 use your Revision 2. If the No Duplicates is used, and the items to filter is 500 or less, use the Hooovahh method, otherwise use Revision 2. I'll think about it, but a hybrid approach might not be a bad idea, even if it complicates things a bit. I'd say of the array VIMs on my palette, Filter, and Remove Duplicates are the ones I most commonly use, so getting the most performance out of these would be good.

NI support sent you to LAVA for a LabVIEW issue? Do we get to charge them if we solve it? Are you saying your palettes are messed up? Can we see a screen shot? If they did get messed up I a reinstall of LabVIEW should fix it so I'm not sure what else is going on. OpenG shouldn't mess with your already installed palette items. It just adds their own by putting the menu files into a folder that LabVIEW then finds.

I might be wrong, but I don't think your Revised v2 is working. The Result array doesn't have the same number of outputs as the other modes. My Array VIMs package at the moment is 2018 and newer so I don't mind conditional tunnels, inlineing, or VIMs (obviously). No Maps or Sets yet, but maybe one day. That being said my Filter 1D is already pretty good with your previous help. OpenG is 1.3, Revised 0.7, my version with your help is 0.7, and if I have the No Duplicates input to my version it is 0.4. I did go through your other VIs that you said had changes, and some had a measurable improvement, some were close enough to what I already had.

Wow there is a lot to go over here. I'm unsure how long it will take to run various performance tests on these. I'm sure they are better then the native OpenG stuff, but I need to also compare them to the changes I made. I see you tend to reuse input arrays which is a great idea. I tend to use indexing and conditional tunnels, with my suspicion being your method is better. Another thing I tend to do is reuse functions in other functions. Like how my Filter 1D Array uses the Delete Elements From Array inside it. This makes for more readable code, and improvements to the Delete function will improve the Filter function. But I will have to run some tests to see if there is a measurable improvement with yours.

You should look into a local LabVIEW User Group. I hear NI is making a renewed effort in these and they are a great opportunity to meet and talk to local LabVIEW enthusiasts about common interests. I personally find the thought of going on my own very daunting. I know several people that have made it on their own, finding contracts, and executing projects successfully. I assume they like the work, and it must pay really well. But for me I'm just happy enough being the LabVIEW Overlord for a company. The thought of having to be my own sales force, finance department, and project manager, on top of the documenter, designer, and developer roles sounds like a lot of work. I'd rather work less for less money.