Background Compilation

[Götz Becker]

Hi,

I just filed a feature request for background compilation for LV RT:

---

Compilation of a rtexe can take of large applications can take very long (especially with configured SCC) and is modal. This causes about 5-10 minute waits between start of a compilation and deployment of the startup exe. It would be _very_ helpful if that could be done in the background.

Maybe this could be done like FPGA compiling. Copy the VI hierarchy to a temp directory and start background compiling from there, ignore SCC for this directory as well.

---

How do you handle long compile times?

I suppose that our times come from all those background SCC checks and analysis of unused lvlib members, but since we can´t change that we are stuck with very high downtime during program/build/test cycles.

Greetings

Götz

[AndyDm]

ZITAT(Götz Becker @ Oct 1 2008, 01:40 PM)

It would be _very_ helpful if that could be done in the background.

How do you handle long compile times?

Hi, Götz!

I have also pretty big project (total compile time over half-hour). Usually I perform "Night build" with some kind of automation. In case if I need full build immeaditely, and would like to continue work with LabVIEW at the same time, I have following trick:

- Copy LabVIEW.exe to LabVIEW2.exe

- Copy LabVIEW.ini to LabVIEW2.ini

- change in ini port number, if used (or disable tcp server): server.tcp.port=xxxx (otherwise message coming about already opened port)

- Start second copy of LabVIEW and perform your build "in the background". During build you can continue working with first copy.

best regards,

Andrey.

Disclaimer: I'm not working with RT, but may be this trick will be OK for you as well. Anyway without guarantees.

[Neville D]

I'm curious:

Why does it take 10-20 mins?

1 Do you have FPGA code?

2 Are you compiling for multiple targets simultanously? (If so, is the code for each of those targets exactly the same?)

3 Do you have a slow PC or lack of memory?

I have a fairly large project ~ 1000+ VI's for PXI-RT target that compiles on my slow laptop in about 2 minutes or so. On the desktop it is faster.

N.

[Götz Becker]

Thx for your suggestions.

my current guess is that the SCC (Perforce) checks in the background are taking very long (sometimes it looks like that some filestate caching is present). Also removal of unused library members takes time (vi.lib contents and the project has about 30 lvlibs).

NevilleD: Are you using SCC? If so which? 

Your questions:

1: no FPGA code

2: compiling for one PXI target only, but many VIs having conditional disable symbols inside shared VIs between Windows HostApp and RT

3: enough memory present (2 GB), but most of the time LV is below 10%. Only at the end one CPU core is completely used by LV.

[Neville D]

QUOTE (Götz Becker @ Oct 6 2008, 01:56 AM)

NevilleD: Are you using SCC? If so which?

Your questions:

2: compiling for one PXI target only, but many VIs having conditional disable symbols inside shared VIs between Windows HostApp and RT

I use Source Safe. I just check out the VI's, work on them and check them back in. No llb's.

Have you tried a project without the conditional disable's to see if thats causing the slowdown? Might be worth investigating. 10-20mins seems like a lot of time wasted for a build.

I have heard that NI uses Perforce too, and I'm sure they would have found a workaround to slow builds if they faced the problem, so maybe it is not related to Perforce or else you are using it in a different way thats causing the slowdown.

Maybe you can investigate Tortoise SVN. Lots of people on LAVA have good things to say about it; also its free.

N.

[Götz Becker]

QUOTE (Neville D @ Oct 6 2008, 06:27 PM)

I use Source Safe. I just check out the VI's, work on them and check them back in. No llb's.

Have you tried a project without the conditional disable's to see if thats causing the slowdown? Might be worth investigating. 10-20mins seems like a lot of time wasted for a build.

Maybe you can investigate Tortoise SVN. Lots of people on LAVA have good things to say about it; also its free.

Perforce is currently set for all our projects and I fear that mixing SCCs would do more harm than good. Currently we are testing a Perforce Proxy installation to speed up things... it "feels" a little faster (but processing of the NI_AALBase.lvlib alone takes about 1-2 minutes). Since we code on the same project with 4 people sitting in 2 different places, I can´t just check out everything (something I normally do when working alone on a software).

To get rid of the conditional disable structures would mean a major rewrite and reorganization of the codebase, another thing we can´t risk at the moment.

I guess I´ll try to talk to NI about that at the VIP 2008 this week in Germany. 

[Neville D]

QUOTE (Götz Becker @ Oct 7 2008, 04:51 AM)

Perforce is currently set for all our projects and I fear that mixing SCCs would do more harm than good.

True.

QUOTE (Götz Becker @ Oct 7 2008, 04:51 AM)

To get rid of the conditional disable structures would mean a major rewrite and reorganization of the codebase, another thing we can´t risk at the moment.

I meant just duplicate your current project, throw out all the conditional disable's and see if that speeds things up. Just as a test. That way you can narrow down the problem to Perforce or NI.

N.

[Götz Becker]

QUOTE (Neville D @ Oct 7 2008, 06:07 PM)

Just as a test. That way you can narrow down the problem to Perforce or NI.

I guess it´s a mixures of both. When I disable SCC in the project loading of the main.vi is fast, but building is still slow while processing the vi.lib stuff. Network sniffing shows that as soon I start the build traffic to the Perforce server/proxy begins. When I disable SCC in the LV options building is fast and no traffic to Perforce.

I guess I´ll have to test with seperate LabVIEW.exes.

Thanks for all your suggestions

Greetings

Götz