Split the LabVIEW executable build

[AdarshaPakala]

Is it possible to split the LabVIEW executable build into 2 parts?

My LabVIEW project size is big and it is in LabVIEW 32 bit version. Due to the virtual memory limitations my build is not going through. Is there any technique to make the build in 2 parts like make one build with referenced VIs and other part for dynamically calling VIs as supported folder?

I'm not sure this is even possible or question to ask, just giving a try.

Thank you

Adarsh

[didje007]

I ran into a similar problem and the solution we used was to build some VI with the exe and others with a source distribution.
We had to make sure the path where both were build were exactly the same.

This worked but it became too anooying, was not reliable and we lost too much time trying to compile our projects that we switch to 64 bit and the problem was solved.

[crossrulz]

I would look into breaking up the application into libraries.  You can then use a separate project to build these smaller libraries into Packed Project Libraries (PPLs).  The main project should then be using the PPLs instead of the libraries.  What this does is push the bulk of building into much smaller builds.  If you changed something in a library, you just need to rebuild that PPL and likely nothing else.  This is a basis of a plugin architecture.

[AdarshaPakala]

@didje007: thank you so much for your input, it gives a good hint

I have not tried this before but I will definitely try this to resolve this issue temporary. What are the build settings we have to pay attention? Can you please point me to a good article/help doc to refer for this exe+source distribution combination build?

At this point of time we can't switch to 64 bit quickly as we have used Hierarchical Waveform Storage (HWS) in our application and there is no 64bit toolkit available for HWS

Thank you

Adarsh

[billko]

---

@AdarshaPakala wrote:

@didje007: thank you so much for your input, it gives a good hint

I have not tried this before but I will definitely try this to resolve this issue temporary. What are the build settings we have to pay attention? Can you please point me to a good article/help doc to refer for this exe+source distribution combination build?

At this point of time we can't switch to 64 bit quickly as we have used Hierarchical Waveform Storage (HWS) in our application and there is no 64bit toolkit available for HWS

Thank you

Adarsh

---

Check to see if you have huge data structures that have default data saved in them.  If you don't need default data saved in them, you might solve your problem without changing things.  (But if your data structures are big with numerics, it doesn't even need default data to get huge, and there's little you can do without refactoring.) 

[AdarshaPakala]

@ crossrulz:

Thank you for your input. This particular project is built in Actor framework and I have class inheritances in it. Will the PPLs work in this case?

I'm little concerned on the PPL and Actor framework as PPL is not suggested method as I saw in one of the video by Darren Nattinger(https://www.youtube.com/watch?v=HKcEYkksW_o)

[didje007]

All option suggested above should be tried.
Building an application with the Actor framework as PPL can be done even if it is not recommended.

It may also be interesting to look for insane object in a mass compile of your directory, (enable the report file so that you can inspect the report with a text editor to look for insane objetct) this may points you toward a type def that could be the source of your error.

There is no documents about the solution we used because it is not really supported by NI.

But you basically need to create an exe which acts as a starting point to launch your program and recreate the structure of your project in a folder with the compiled code so that it can be called dynamically from the exe.

I know this information is not the most helpful but it really depends on the structure of your project and the way your functions are called. In our project a lot of code is called dynamically. We recreated the structure of the project in a directory with the compiled code accessible to the exe and the source distribution.

Best of luck on this as it could be difficult to find a solution

[crossrulz]

---

@AdarshaPakala wrote:

Thank you for your input. This particular project is built in Actor framework and I have class inheritances in it. Will the PPLs work in this case?

---

Yeah, that adds a lot of complication.  To do it properly, you would have to build the Actor Framework into a PPL, which is the prime example of what can go wrong in Darren's presentation.

[Kyle97330]

The assorted options for splitting builds could help, but have you also looked into other things to slimline your build or checked for other reasons the build could fail?

• Make sure that the GDI object limit isn't what's holding you back
• Turn off debugging in the build configuration if you haven't already
• Disable your antivirus during the build process
• Check your code for included files that aren't needed, and find ways to trim them
  • Remember that all files included in a LabVIEW class are included in the build, needed or not, so consider removing things from classes that might have been included without a good reason
  • Check to see if you have any exceptionally large VIs that shouldn't be (probably due to either large amounts of default data included or abuse of nested Malleable VIs)

[BertMcMahan]

There's a chance you could have some large classes due to LabVIEW storing a class's mutation history. Clearing that can significantly reduce sizes:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-histo...

https://lavag.org/topic/14548-class-mutation-history/