Multi-core LabVIEW IDE

[Thoric]

I seem to spend a lot of my time in the LabVIEW IDE waiting. Waiting for LabVIEW to load dependencies, or do this or process that. For some projects with FPGA and CompactRIO I've calculated that I spend about 80% of my time just waiting for LabVIEW development environment to catch up.

Given LabVIEW's multi-core nature, it seems embarassing that I can create code to run blisteringly fast on a massively multi-core number-cruncher, yet the IDE itself is painstakingly slow. I wonder how much of these delays could be mitigated by a multi-core capable development environment? LabVIEW currently runs on just one processor, and with the increasing prevalence of multi-core CPUs as opposed to faster indivudal core speeds, I wonder if the chaps at NI are thinking of taking the plunge into a multi-core integrated development environment? I seriously hope so.

[SteenSchmidt]

80% time spent waiting on the IDE? That's massive. I think I spend maybe 1% of my dev time waiting on actions. Most of this wait is loading, not compiling. And most of the loading I'm waiting on is due to limitations in harddrive or network performance. When I'm developing on a machine with an SSD disk I spend less time waiting on loading dependencies than when I'm on a machine with a mechanical drive - the performance gain with SSD is noticable.

I'm only annoyed of the IDE speed when building an application or when compiling FPGA code (and most of the latter can even be disconnected from the dev environment). On rare occasions it can be annoying to load a LabVIEW project with several thousand dependencies, but then again, this goes much much faster on an SSD equipped laptop. I don't think either of these processes are parallelizable to any great extent.

/Steen

[Thoric]

Steen,

With one project in particular (RealTime and FPGA), it takes about 15 minutes to load the main VI. This has about one thousand dependencies. When loading, the CPU of one core is at 100% throughout the entire load period, and the hard-disk is barely active. Switching to an SSD drive will not make any noticeable difference, but clearly the LabVIEW IDE would benefit from taking advantage of more than one core.

Also, when I build the application (which is quite often during de-bugging), it similarly uses one core at 100% for about 10 minutes, which could surely be improved by making the process multi-core compatible. I understand that's probably not easy, but with the increasing propensity for multi-core as opposed to increasing clock speeds it is surely an inevitability.

As an example: I have two laptops, my old 2.4GHz dual core, and a new 2.2 GHz quad core. Indeed, speed tests show the new laptop runs the IDE slower than the old.

[SteenSchmidt]

15 minutes to load a VI without the delay being caused by disk or network IO, that sounds like alot of code getting recompiled during the load? Maybe you have something askew in your tool chain? It's very rare I experience such long VI load times, but on one occasion it was consistent: on Windows Server 2008. There might be some issues on server OS'es.

Otherwise it would be worth tracking what exactly is taking so long, as that's clearly not expected behavior I'd say.Has NI taken a look at that VI?

Regarding the build process; Ordinary application building can often be parallelized (even GNU make supports parallel jobs), but I'm not convinced that FPGA compilation can ever be parallelized (not "hard" but "impossible"). I'm not sure though.

/Steen

[Thoric]

Steen,

For my CompactRIO codes, which can get quite large (thousands of VIs), I find the load time is always proportional to the size, and 15 minutes for my largest projects is typical. I have several installations of different versions of LabVIEW, each on different partitions/PCs, and they all behave the same. I doubt they all have something 'askew'.

I appreciate that FPGA compilation can unlikely be parallelised, this idea is not about that, but the LabVIEW IDE.

[SteenSchmidt]

Ok, I understand your frustration, it's just that I don't experience the same as you, except in a few limited situations. But there must be some deciding difference between our projects - maybe the resources we use. I tend to never use Shared Variables for instance. Do you have a lot of those in your code? Do you use the Scan Interface on the cRIO, so your VI might load alot of FPGA-access code?

There must be a difference, as I work heavily with LV Real-Time and large applications as well. Just for a quick test, I loaded up three typical projects on two different laptops;

Case 1: i7 M620 @ 1.2 GHz (running on battery, wall-powered speed would've been 2.67 GHz), 2 Gb RAM, WinXP SP3, LV Real-Time app for PXI-target, ~600 VIs: 23 seconds for main VI to load (LV 2010 SP1).

Case 2: i7 2720QM @ 2.2 GHz, 16 Gb RAM, Win7 64-bit, LV Real-Time app for cRIO, ~1500 VIs: 11 seconds for main VI to load (LV 2009 SP1).

Case 3: Same machine as case 2, LV Real-Time app for cRIO, ~1000 VIs: 13 seconds for main VI to load (LV 2009 SP1).

That's very different? For the record I'm all for an MP-capable IDE, but I just think there are some things that might improve your use cases before the IDE gets a complete overhaul (again). I'd die if I should wait several minutes for my main VI to load. I almost *did* die when I was forced to work on that Windows Server as dev platform 🙂

Cheers,

Steen

Additional note: I just loaded case 2 a couple of times while monitoring the CPU-usage in the task manager; The i7 2720QM has 8 logical CPU-cores, and none of those barely moved beyond where they were at idle. The highest CPU-load on one unit was probably around 10%, so I guess this load was mostly limited by some other system resource but the CPU. I don't know, it's very shallow testing for now obviously.

[JackDunaway]

For what it's worth, today I was using "Find All Instances" in a project of a few thousand VIs, and noticed that one core of a quad core was railed out while the other three were idle. This Find operation took roughly ~40sec, and may have only taken ~10sec if parallelized.

The way this idea is worded is probably too broad to actually get accepted and implemented, but maybe it can be a launching point for a few specific actionable requests to make the IDE faster!

[pavanb]

please see this exchange. https://decibel.ni.com/content/polls/6634#/?page=2 

If possible, pushing this task during idle/night or during compile is workable, the edit time responsiveness is important. Like the VI property slider, just at global/project level.