Application build time very long

[itronChiraldude]

I have several large projects (> 2,000 VIs and lots of classes) that take 5-7 minutes to build into an application.  While watching the progress of the build, at least 30% of the time is spent "compiling", even if I have run a Mass Compile on the project.   

Why does this happen?  Isn't the code already compiled?  

What can I do to speed up the build process?  

[cbutcher]

If you have a lot of libraries that don't change much and either you already have a build process, or the build process is fairly simple, you might find some benefit from using Packed Project Libraries.

These create a compiled copy of a library (lvlib) into a single lvlibp file, which can then be referenced by your application to both vastly reduce the number of files/VIs you need to open and also reduce the number of things that must be compiled.

If I was to guess about compilation, I'd say the build specification might apply different optimisation settings to your default "Save" action or the Mass Compile, but that's only my guess.

[billko]

I think that if you have dependencies that are of a different (older) version of LabVIEW, they get compiled before getting stuffed into the executable.  Plug n Play drivers are a good example of this issue.  I've seen "current" drivers as old as LV 8.6.

[wiebe@CARYA]

---

@itronChiraldude wrote:

I have several large projects (> 2,000 VIs and lots of classes) that take 5-7 minutes to build into an application. 

---

I'd be very happy with 5-7 minutes compile time. It's more like 12-15 min. for me (3800 VI's, 300 classes).

Besides the PLLs, I don't think there's not much you can do about it.

I limit the times I need to build, and when I have to I take a break.

It would be interesting to know why compiling already compiled VIs is needed, if that's indeed what is happening...

[LucianM]

5-7 minutes is not that long for that project size. How many classes do you have? Do you also use actor framework? You can find more information about build times in this thread and some build time metrics here.

Beside the things you will find in those threads, I would also minimize circular dependencies and make sure Error list window and VI hierarchy and LabVIEW class hierarchy windows are closed when building. If you are using AF, always use abstract messages when sending from nested to caller.

---

wiebe@CARYA wrote:

It would be interesting to know why compiling already compiled VIs is needed, if that's indeed what is happening...

---

In executable debugging is disabled so that would be at least one reason to recompile all VIs when building.

---

[wiebe@CARYA]

---

@LucianM wrote:

---

wiebe@CARYA wrote:

It would be interesting to know why compiling already compiled VIs is needed, if that's indeed what is happening...

---

In executable debugging is disabled so that would be at least one reason to recompile all VIs when building.

---

---

Good call.

[Kyle97330]

---

@LucianM wrote:

5-7 minutes is not that long for that project size. How many classes do you have? Do you also use actor framework? You can find more information about build times in this thread and some build time metrics here.

Beside the things you will find in those threads, I would also minimize circular dependencies and make sure Error list window and VI hierarchy and LabVIEW class hierarchy windows are closed when building. If you are using AF, always use abstract messages when sending from nested to caller.

---

wiebe@CARYA wrote:

It would be interesting to know why compiling already compiled VIs is needed, if that's indeed what is happening...

---

In executable debugging is disabled so that would be at least one reason to recompile all VIs when building.

---

---

All references from one VI to another would need to be "re-pointed" from their locations in vi.lib, instr.lib, your project folder, and any other locations referenced to point to the EXE application itself or one of its subdirectories.  I suspect that's also quite a lot of work to do.

[Yamaeda]

I did a project which had ~2000 vi's and lots of interdependancy, it took 75 mins ... That platform and framework is now heavily changed.

/Y

[Hooovahh]

I couldn't find many instances of long build times in modern versions of LabVIEW but I'm struggling here a bit.  I have a medium to large sized project, probably 3k or 4k VIs, library based actor design, with probably about 20 libraries.  My build time has just continued to grow and is probably about 30 minutes now.  I can't know for sure since it stays on Initializing Build for probably 90% of the time with no progress, then zips by and is done.  This is with separate compile code on for VIs, however I probably missed some.  These are all local files on an SSD and a modern machine.  I've checked out the source on another machine and it has an even longer build time.  PPLs aren't an option since the majority of the code is shared between RT targets and Windows.

Sometimes after waiting 30 minutes I'll get an out of memory error.  In these cases I'll clear the compile cache, re-open the main VI, save all, then build again.  Typically after another 30 minutes I'll have a working EXE.  However sometimes it will wait 30 minutes then tell me a VI is broken that isn't.  I'll open it, confirm it isn't broken, resave it, then clear compile cache, re-open and try again.  By the third time the build is fine.  So this means my actual build might take from 30 minutes to 2 hours.  Very frustrating and I can't think of a way to make it better.

[wiebe@CARYA]

---

@Hooovahh wrote:

I couldn't find many instances of long build times in modern versions of LabVIEW but I'm struggling here a bit.  I have a medium to large sized project, probably 3k or 4k VIs, library based actor design, with probably about 20 libraries.  My build time has just continued to grow and is probably about 30 minutes now.  I can't know for sure since it stays on Initializing Build for probably 90% of the time with no progress, then zips by and is done.  This is with separate compile code on for VIs, however I probably missed some.  These are all local files on an SSD and a modern machine.  I've checked out the source on another machine and it has an even longer build time.  PPLs aren't an option since the majority of the code is shared between RT targets and Windows.

Sometimes after waiting 30 minutes I'll get an out of memory error.  In these cases I'll clear the compile cache, re-open the main VI, save all, then build again.  Typically after another 30 minutes I'll have a working EXE.  However sometimes it will wait 30 minutes then tell me a VI is broken that isn't.  I'll open it, confirm it isn't broken, resave it, then clear compile cache, re-open and try again.  By the third time the build is fine.  So this means my actual build might take from 30 minutes to 2 hours.  Very frustrating and I can't think of a way to make it better.

---

Any .vims?

They are great, but do seem to mess things up.