LabVIEWs response time during editing becomes so long

[jgcode]

I don't particularly like how that option is worded, but that's my understanding of what it's supposed to mean

Damn, I was way off with my interpretation.

[crossrulz]

Damn, I was way off with my interpretation.

So was I. Luckily Christina set me straight in her blog post.

[Daklu]

Thanks Darren and Crossrulz for clearing that up.

[SuperS_5]

Every time I have seen this problem, the computer did not have enough RAM, and the swap file was heavily used. Upgrading the system RAM solved the problem. If you cannot upgrade the system RAM, and have windows 7, then ReadyBoost can be used to augment the system RAM. I currently have 8GB of RAM. (I was running out at 6GB)

[Thomas Robertson]

Just wanted to chime in on this Zombie thread and say I have all of these problems and it's driving me crazy.  LV2023, Roughly 18,000 vis in the project.

[Neil Pate]

@Thomas Robertson 18k VIs? OK, that is quite a big project. Have you tried splitting things up, maybe introducing a few PPLs?

[hooovahh]

11 hours ago, Thomas Robertson said:

Just wanted to chime in on this Zombie thread and say I have all of these problems and it's driving me crazy.  LV2023, Roughly 18,000 vis in the project.

My projects can be on that order of size and editing can be a real pain. I pointed out the difficulties to Darren in QD responsiveness and he suggested looking for and removing circular dependencies in libraries and classes. I think it helped but not by much. Going to PPLs isn't really an option since so many of the VIs are in reuse packages, and those packages are intended to be used across multiple targets, Windows and RT.  This has a cascading affect and linking to things means they need to be PPLs, made for that specific target, and then the functions palette needs to be target specific to pull in the right edition of the dependencies. AQ mentioned a few techniques for target specific VI loading, but I couldn't get it to work properly for the full project.

[Softball]

Hi

NI has always tried to 'optimize' the compiler so the code runs faster.

In LabVIEW 2009 they introduced a version where the compiler would do extra work to try to inline whatever could be inlined.

2009 was a catastrophe with the compiler running out of memory with my complex code and NI only saved their reputation by introducing the hybrid compiler in 2010 SP1. Overall a smooth sailing thereafter up to and including 2018 SP1.

NI changed something in 2015, but its effect could be ignored if this token was included in the LabVIEW.in file : EnableLegacyCompilerFallback=TRUE. 

In LabVIEW 2019 NI again decided to do something new. They ditched the hybrid compiler. It was too complex to maintain, they argued. 

2019 reminded me somewhat of the 2009 version, except that the compiler now did not run out of memory, but editing code was so sloow and sometimes LabVIEW simply crashed. NI improved on things in the following versions, but they has yet to be snappy ( ~ useful ) with my complex code.

Regards

 

 

Edited 1 hour ago by Softball
clarification

[ShaunR]

58 minutes ago, Softball said:

Hi

NI has always tried to 'optimize' the compiler so the code runs faster.

In LabVIEW 2009 they introduced a version where the compiler would do extra work to try to inline whatever could be inlined.

2009 was a catastrophe with the compiler running out of memory with my complex code and NI only saved their reputation by introducing the hybrid compiler in 2010 SP1. Overall a smooth sailing thereafter up to and including 2018 SP1.

NI changed something in 2015, but its effect could be ignored if this token was included in the LabVIEW.in file : EnableLegacyCompilerFallback=TRUE. 

In LabVIEW 2019 NI again decided to do something new. They ditched the hybrid compiler. It was too complex to maintain, they argued. 

2019 reminded me somewhat of the 2009 version, except that the compiler now did not run out of memory, but editing code was so sloow and sometimes LabVIEW simply crashed. NI improved on things in the following versions, but they has yet to be snappy ( ~ useful ) with my complex code.

Regards

 

I still use 2009 - by far the best version. Fast, stable and quick to compile. 2011 was the worst and 2012 not much better. If they had implemented a benevolent JSON primitive instead of the strict one we got, I would have upgraded to 2013.