Is there a way to SHORTEN the time of compiling

[Nick.song]

Hey guys,

It's extremely time consuming when you make only little change of the labview project and the whole program has to be recompiled all over again!

It often takes me 30 mins or so. It almost drive me crazy....

Is there any one who have samilar experence and find out a way to solve it or even just shorten this boring waiting?

Thanks a lot!

Nick

[smercurio_fc]

Would you care to provide some details?

Like size of project?

Like version of LabVIEW?

Like what the project contains?

Like what changes you are making?

Like what kind of computer you have?

Like whether you have massive amounts of data stored on the front panel?

You know, details like that which would provide someone with the hope of actually being able to answer your question.

[Nick.song]

Hi Smercurio_fc,

My project is around 22 MB, using LabVIEW 2010 version, containing a sbRIO project with both I2C and SPI communication, having very clean front panel. 

My desktop has Intel Core 2 CPU 6300 1.86Hz, 3.00GB RAM (5 GM installed but the 32-bit system).

Even when I just change a variable type in a subVI it will recompile again. 

I guess it's because of the size of my project.

Just want to know whether there is a way to make life easier in debugging.

Thanks.

Nick

[Yamaeda · Accepted solution]

You cant really affect the time per se, but you can affect how much/often it recompiles.

E.g. this variable type, is it used in alot of vi's? If it's some common AE, maybe it can be split in a couple different ones?

You can write protect a folder which shouldn't really change and set the LV setting of "Treat read only VI's as locked"

There's also a LV setting in the .ini-file which can ease the optimization which'll reduce compile/save times.

/Y 

[Nick.song]

Thanks Yamaeda, I'll try to do that later!

Nick

[nathand]

You mentioned a sbRIO.  Are you referring to compiling the FPGA portion of your code?  If so, long compile times are unavoidable.  The best thing to do is test as much as possible prior to compiling.  You can set the FPGA code to run on the development machine in simulation by right-clicking on the FPGA target within the project explorer.  Also, under the FPGA target properties, Xilinx options, you can set the Design Goal to "Compilation Time."  It is also possible to run the compile server on a separate, possibly faster, computer, if you have one available.

[Nick.song]

Thank you Nathand! Your information is really helpful!

Nick

[JÞB]

And of course, you can write fewer bugs!  I found this to be be very effective in reducing debug time!   Yamaeda is spot on about looking into the code style.  A highly modular approach where you encapsulate related action can lead to some blocks of your code that are independantly testable so most of the code could be unit tested prior to compiling the whole shooting match.

[Nick.song]

Lol! That's true. If everytime it runs perfectly, even 1 hour for compiling is not a problem any more. Yeah, you are totally correct on the point that trying to use a highly modular approach. While, since I basically dealing with communication protocals, which requires most of the sub VIs to work intersecting with each other. So... Thanks very much for your help!

Nick

[rolfk]

While there are certainly things that can be hard to seperate into submodules, usually it's possible to write components that have little or no dependency on other parts in your application. Especially when you deal with communication protocols it is common to write actual drivers that provide a standard interface that once tested and deployed don't need to be changed anymore and of course never should depend on anything else in your project. Try to see it from the point of developing this driver in a way that you can actually give it to someone else for use, without that person having to know anything about the rest of your project. If you have achieved that, then this driver definitely wouldn't be affected by whatever change you may do to any other part in your project and LabVIEW wouldn't have to recompile it at all.

In general I have found that FPGA compilation times are hard to shorten and therefore testing and thinking not only twice but at least three times before doing a new compile actually is worth it, but as long as LabVIEW on a host is performed I have never seen compilation times that are excessive even in projects with 1000 VIs and more. Yet they are modular and tend to have lots of subVIs in an attempt to modularize the code. While I agree that the rule of the diagram never being allowed to be bigger than a screen should not be followed zealously, I have typically very few VIs that would not fit on even a 1024*756 pixel screen, despite my Full HD screen.