LV 2016 frustrations regarding memory use and Autogrow feature

[BBend]

I have been using Labview for 10+ years and upgraded to new releases each year. In the beginning I stuck with 8.6 for quite some time, as I wasn't too impressed with the following releases (2009-10), but at some point you need to upgrade, so from 2012 onwards, I chose to upgrade as new versions came out. Every new release has added new functionality, which I must admit, I'm not the best to take full advantage of. So unfortunately my experience with newer versions have mainly been more negative than positive. Esp 2015/2016 I've experienced a large increase in VI size and memory allocation for a large application I've been working on last years. It handles and plots rather large datasets (0.5-1 mill points), but with 2016 it allocates 1.3Gb before datasets are loaded and it soon runs out of memory at 3Gb+. When I run executables from 2013 it allocates far less memory than 2016. This is not because of bad programming as I have always been careful to initalize arrays and other tricks to save memory, so it is clear (to me) that 2016 is more "sloppy" with memory allocation than earlier versions. As it is I seriously consider to reinstall 2013 to see if this works better for my application. In the long run this is not a good solution, so I would like some views about from others with same experience, and if there are some tricks to improve memory use. I have not upgraded to 2017 because I see a negative trend on performance. Labview has never been ideal on large data sets, and it seems like LV has gone the wrong direction regarding memory use, for unknown reason (data integrity?)

One other thing that drives me crazy is this Autogrow feature, that makes my Block diagram grow out of proportions. I use a Prod/Consumer framework, and the Case- structure keeps growing as new cases are added. I have deselected Autogrow on every frame border (loops, cases), and in Options too, but it still grows. The worst part is that it moves around controls, indicators and constants relative to functions,  so wiring looks horrible. For a large app it is very time consuming to manually rearrange wires etc, which I did once, but now it keeps messing up again. To me this looks like a bug. Any suggestions on how to sort this out?    

[Gregory]

Your autogrow sounds a little buggy, but if you want to turn it off for a batch of VIs, you can look at this code.

[Gregory]

A million points doesn't sound like that much. Even with DBLs I think that's about 8MB, so there is definitely something else going on under the hood.

[BBend]

Thanks gregoryj for the code. Unfortunately it did not work as hoped. Picture shows an existing case, before and after creating a new empty case, which is same as before running Batch VI.  Notice how the constants shifts right relative to code. I only payed attention to this when Case got really big and messy because of "shifted code", and I did a major cleanup moving the stretched code together, which takes some time on a large Case with hundreds of constants etc. The thought of doing this periodically, because I can't prevent it, really scares me! 

The strange thing is that it doesn't need to Autogrow when adding a empty case, so yes it does appear buggy, but to say that "my" autogrow is buggy and not everybody elses is, sounds strange to me. I guess I'll have to upgrade to 2017 and see if that works better

[BBend]

Yes a mill DBLs is not much, but that's just an extract from a 2D arrays, and with multiple plots and array operations it adds up. The program allocates a lot of memory, always has, and will continue to increase as code is added. My point is that when going to 2016 from say 2013 the main VI size more than doubles from 6M to 16M (When Saving for Previous version to 2013, the VI size shrinks to 8.7M), the executable VI from 8M to 28M. When running 8M EXE file it allocates 200M when started and 28M version allocates 1G+ data, so it looks like 2016 pre-allocates a lot more buffers than 2013. This is not an exact comparison, since code is added between versions, but still I find it strange that the difference is so large. I will do some more testing after I have installed 2013 again to compare performance.

In short I'm not looking for tricks to optimize my code. I just need to find out if others have had similar experience. Again, I'm not sure what causes this, and I'm not saying that LV is developing in wrong direction regarding large data performance, as there are so many variables that adds to this equation, but my simple findings should be of concern for more than me.

[BBend]

Update: Just installed 2017. Same problem with Autogrow. God knows what the memory hit will be. I'll stick with 2016 for now... 

[Yamaeda]

Your Case structures grow when you add empty cases? I've never heard of such a thing.

/Y

[BBend]

Update 2: It turns out that the Turn off Autogrow VI didn't work as intended when selecting top directory with all my VIs, so I just copied the main VI to a separate directory and ran it once more, and then it turned off AG on all case/loops etc, and now it work fine  Now I just need to tidy it up once more and never turn on AG again. I suppose it is nice to have for smaller apps, but once it gets large, it can get out of control. It is strange that you can not turn off AG in Options for present code, only for new code.

[billko]

---

@BBend wrote:

Update 2: It turns out that the Turn off Autogrow VI didn't work as intended when selecting top directory with all my VIs, so I just copied the main VI to a separate directory and ran it once more, and then it turned off AG on all case/loops etc, and now it work fine  Now I just need to tidy it up once more and never turn on AG again. I suppose it is nice to have for smaller apps, but once it gets large, it can get out of control. It is strange that you can not turn off AG in Options for present code, only for new code.

---

It's actually not so strange at all.  Take the option to change the label position on your terminals and constants.  Only new block diagram objects take the change.  (However the cleanup tool will force all the objects to update.  You can limit this effect by placing a one frame sequence structure around the stuff you want to update, selecting it, then use the cleanup tool (then remove the sequence structure).  Sometimes this action will want to resize some stuff, so be ready with the undo button.)

[BBend]

Yes, I find it really strange too that the Case- structure grows when adding an empty case, but it is true. I'm the first to admit that my app has grown a bit out of proportion, and could need some cleanup, and I might have triggered some weakness in the Autogrow algorithm. So I think this function must be used with caution esp for larger apps, as it is far from perfect, pulling code appart in an ugly way, and difficulties turning it of for all instances. Luckily there are a lot of smart people on this forum coming up with workarounds when needed. So big thanks for that!