Build application crash to desktop

[Yamaeda]

So a colleague crashes when building his application and i can see we're hovering close to 3GB (though the end product is ~40Mb when it last succeded).

We could switch to 64 bit, but i want to know what can be done and what affects memory usage while building?

What about Inline function vs Shared and Preallocated ones, how will they affect memory usage while building?

What about circular dependancies, and how to find them?

How can build memory usage be reduced/optimized?

I saw a tip about setting the paging file in another thread, we haven't done that yet and in that one it changed from crashing to getting an Out of memory error, which i suspect is what'll happen here too.

/Y

[thols]

Darren has some answers. Although the post is primarily about speed, it applies to memory too I would say.

I once noticed my build taking way more time, and the memory also increased a lot more. I had made some new circular dependencies that time. 

I would also mass-compile to make sure everything is in order. Bad VIs can mess up the build.

Another tip is to create a fresh project and build. I have had something mess the build up, then recreate the build in a new project in the same way and it then works. 

Hope your colleague recovers from his crash 😀.

[Yamaeda]

@thols That plugin was cool, but i don't see how it shows circular dependencies. What if you don't use classes though?

[Kyle97330]

---

@Yamaeda wrote:

@thols That plugin was cool, but i don't see how it shows circular dependencies. What if you don't use classes though?

---

I made a post here about how to use that plugin to spot circular dependencies:

https://forums.ni.com/t5/LabVIEW/Anyone-else-having-DVR-In-place-element-structure-bug-error-1556/m-...

If you want to utilize the method that tool uses but don't like its visual display, I looked inside it and "under the hood" it uses a private method that's normally hidden from users which I outline a bit here:

https://forums.ni.com/t5/LabVIEW/Tool-to-analyze-dependendies/m-p/4343243/highlight/true#M1273649

I have actually used that private method to create a tool that looks for circular links in my company's projects.  It's integrated with my company's codebase so I can't share it directly, all I can say is that it does seem to work as long as you ignore common memberships in "lvlib" files, since (per Darren) those do not cause the circular dependency problems that he addressed in the Nugget.

[Kyle97330]

To add some more info about application builds unrelated to circular dependencies:

One thing to do is to make sure you're not running out of GDI objects.  You can increase the built-in Windows limit of 10000 in case you're hitting that limit:

https://stackoverflow.com/questions/38612364/how-to-increase-the-maximum-amount-of-gdi-object-for-wi...

Other things you can try:

* On the build PC, check to see if there are any files in the instr.lib and user.lib folders that you don't need for the build, and remove them (temporarily) from those folders before launching the instance you built with.  LabVIEW doesn't actively load VIs from there if you don't need them, but it does scan those folders and put them into the palettes as icons which does take some of its memory away.

* Check to make sure the VIs are all pre-compiled.  If you've got "Separate compiled code" enabled on all VIs, then just make sure to open every file in memory to get them added to the compile cache, then close and reload before you build.  If you have some or all of your VIs that don't have that enabled, make sure you do a "Save all" before building, otherwise you have extra stuff in memory (i.e. you have both the original compiled code that your IDE has flagged as needing a recompile, as well as it having to do the recompile on the fly during the build process).

[Yamaeda]

GDI wasn't a problem, i think we hovered around 500. I'll check out the instruction link, thanks!