Build errors : Memory usage during compilation

[Intaris]

We have been getting regular errors when trying to compile our software recently.  I know our software should be more modular, I know there are steps to take to make this problem go away but right now and for the medium term we have what we have.  I'd love to change this side of things but it's just where we're at for the time being.

Accepting that, I noticed today that a colleague can compile fine whereas I get an "out of memory" message mosty during the build initialisation process (sometimes I get as far as "Processing...." very rarely I make it to "Compiling....", I never make it to "Saving....").  When observing LabVIEW in the Task Manager (I have Win 7 64-bit 8GB RAM) I see that LabVIEW is using around 3200 to 3300 MB RAM.  My colleague when he's compiling (Same source code, same LabVIEW Version, same Toolkits installed : Real-Time and FPGA) his memory usage never goes over 2800 MB and the compilation completes no problem.

We both restart LabVIEW before traing to compile, both did a fresh check-out of the code for attempts to compile.

The only difference is that he has 16 GB RAM whereas I have only 8 GB.  Could this be a "contiguous space" problem?  But if so, why is his overall memory usage so much lower than mine?  What can affect the memory required during a build.  My LabVIEW installation is relatively new seeing as I have reinstalled LabVIEW and Windows a couple of months ago.  I shouldn't have accumulated too much crap over that time.

I have tried clearing compiled cache.  didn't help.  Anyone got ideas?

[Thoric]

What happens if you borrow his RAM and compile on your computer? Might help you isolate the RAM as being a factor here...

[Intaris]

I have already ordered more RAM.  The extra RAM is probably cheaper than me typing this message (Not quite, but nearly).

It would seem likely that having more RAM might help but the observed RAM usage for the same work is a few hundred MBs less than when I attempt the same thing.  That's the part that's annoying me.  How can adding more RAM lead to requiring less RAM?

[Intaris]

I have now installed another 8 GB RAM and the results are the same.

On my PCI cannot compile (Memory goes over 3300MB whereas another colleague can compile no problems (Memory barely goes over 2800MB).

Same LV Version, same code.  I even looked at what LV toolkits I had installed and uninstalled those my colleague doesn't have (Database toolkit, Data finder etc).  No difference.

Anyone anywhere got any idea what's going on?  Is there some LV switch in the INI causing me to allocate hunderds more MBs than my colleague? Supersecret perhaps?

[Thoric]

I noticed today there's a little bit of info in the Help that suggests a higher Compiler Optimisation value will use more RAM. Have you set a higher value than your colleague in your Options > Environment > Compiler pane?

See step 9: http://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/compiler_optimizing_for_execution_speed/

[Intaris]

Forgot to mention tbat one. Both set to 5. Im giving up at this stage. We may clone my colleagues pc and dedicate it for building......

[ZX81]

I've had a mess on one computer that might be related.  I loaded a project with its own duplicates of all the LabView built-in .vis that it used (that's because the project came from a TestStand deployment instead of sources--not worth going into why here).  After we loaded the project, we started resolving conflicts, and at each step, it kept saving changes back to .vis in C:\Program Files(x86)\National Instruments\LabVIEW 2014\......  Over time, we ended up with a hodge-podge of .vis in the 2014 install of LabView that pointed to 8.6 version .vis from the project.  Even when we tried to open a new project, standard .vis kept referencing back to the old project's duplicates.

In short, the .vis that are part of LabView may be different from one computer to another.  Make back-ups before monkeying around.  But you ought to be able to copy the C:\Prog files\NI\LabVIEW 20xx\vi.lib and instr.lib from one install to another (make SURE they are the same service pack and patch level).  That could help.

A quick way to check if your dependencies are hay-wire is to switch to the folder view in your project.  You can see if it is getting dependencies from anywhere besides your project and C:...LabVIEW 20xx\vi.lib and instr.lib.

--

The amount of RAM you have shouldn't affect crashes or the memory needed for an application.  The amount of swap space you have should affect crashes, but shouldn't affect memory needed for an application.  Having more RAM will avoid the need for swap space, so applications will usually be MUCH faster.

At about 3.3GB of RAM used, the application is pushing the 32-bit application limits.  32-bits can address 4GB, but the reported size used doesn't (I'm basing this on x86 development days) include memory needed for certain overhead like shared .dlls and OS calls.  You might (MIGHT) have better luck with a 64-bit install of LabView.  Unfortunately, 64-bit LabView doesn't allow database access (as of 2014; I haven't kicked the tires on 2015 yet).

But, as a famous, former CEO of a major software vendor supposedly said, "640K of memory is all that anybody with a computer would ever need". [the quote was supposedly from a 1981 conference, but unsubstantiated.]

[Intaris]

I have a relatively fresh LV 2012 install (I reinstalled Windows about 2-3 months ago) and have no other LV versions on my PC.

Today for some reason my PC decided to actually compile.  It got there by the skin of its teeth (over 3.1 GB) but it got there.  Just don't ask me what changed.

I had previously set the compile complexity lower but perhaps it needed a couple of days to think about it, even though I actually deleted my compiled cache in between.

Weird.  Moving to 64-bit LabVIEW is not an option.  We have customers with 32-bit OS.

BTW, apparently the 640k quote is one of those famous quotes which were never actually made (at least by the people they are appropriated to).