Jon S

I got some more information on the flickering. It is caused when we do a redraw of the canvas. If you slow down the video of LabVIEW 2015 and before you can actually see the flicker once, when we redraw the canvas. We introduced live redraw in 2016 which makes the flicker obvious because it happens multiple times. I did file CAR 713251 for this which one of my colleagues will prioritize among the other work his teams have on their backlog.

With respect to the CAR 493662, I agree that the workaround isn't great. It's only an option if you are both the author and consumer of the .NET Assembly. If you are just using an assembly installed on the system, you can't call the other constructor. This doesn't help your situation, but I have a team that is currently working on .NET for NXG and I did make this an acceptance criteria of their work. I verified in a beta build of NXG 3.0 that we are able to call both of the overloaded constructors.

Quote

 I personally believe that new features should be delayed till all the bug are fixed.

This is similar to the model we are moving toward. The Product Owners have the final say of when we toggle on a feature. It's our role to hold the line for quality and workflow completeness when it comes to turning on features. Hopefully our change in process is noticeable as we move forward.

Thanks again for the candid feedback here. It does help myself and other POs have a better grasp on the heartbeat of the community.

Hey Everyone,

I was pointed to this thread by a colleague and wanted to answer some of the questions that were posed as well as gather more specific feedback on some of the things that were asked.

First off, we do have engineers at National Instruments that are using LabVIEW for real world-applications. Our Systems Engineers and Applications Engineering Specialists work on some of our largest customer applications. They specifically create and work on real-world code. For LabVIEW NXG, we have a LabVIEW Lead User team that has met with a number of customers and converted their applications to NXG. Their team goal is to provide feedback to the NXG development teams and Product Owners to help us prioritize what we need to be working on.

While a lot of my recent focus has been on LabVIEW NXG, I did want to follow up with the comments about the dragging performance of the LabVIEW IDE first brought up by Neil. I spoke with the developer of live drag about the behavior you are seeing as well as did some testing of it. The behavior you are describing when dragging objects across diagram boundaries (e.g. the drawing delay when dragging from outside a loop to inside) is actually intentional. It was a compromise designed in to help performance when dragging very large selections. The intended user interaction is that if the user really wants to see what the code would look like before releasing the objects, they could stop moving the mouse cursor. If we don't detect movement, LabVIEW will redraw the code. However, it seems this is being inferred is that there is sluggish behavior when moving things between diagrams. If you drag across diagrams and immediate release are you seeing a delay in moving the code? Your comment about seeing the same behavior when moving a single primitive makes me suspect that we aren't struggling to keep up from a performance stand point, rather the UX that we designed is not having the desired effect. Worse off, it sounds like it's having a negitive effect.

As an aside, we don't need to do a full compile when we are doing live drag. Type propagation is just the part of compile that determines wire and node data types. When we are doing live drag, this is the only part of the compilation process that we have to do.

Thanks for the feedback everyone. I know there were some other generic performance issues that were mentioned, and I don't want to give the impression that I'm ignoring them. I just wanted to focus on the issue presented by Neil first.

Jon S
LabVIEW NXG Product Owner

Hmm..."commands which involve many files" screams virus protection software to me. Are all of the problem areas you see when doing disk I/O? I know I've seen cases where building a large project in Visual Studio can be slowed down by a factor of 2 or 3 if you have a virus protection on. Can you try disabling this or any file indexing programs that you could have on these machines? If it is a virus protection you could see about adding exceptions to folders that you commonly build to.

Are the installations the exact same on both machines? As I mentioned before if you have DSC activated we do an additional check that requires loading libraries. There could be other things that I'm not aware of but that is definitely one possibility.

Another thing to look at is processing power of a single core on the machines. Some older machines have a higher CPU speed with only one core while a newer machine may have multiple cores that are lower power. When building an application is single threaded because of the way our compiler works. If your older machine has a higher speed on one CPU that could make a difference although I wouldn't expect it to be a huge difference

How much shorter is your build?

This has become common place in my larger application which also uses classes extensively. I'm not sure if it's the actual use of classes, or the proliferation of VIs as you start to get a bunch of read/write accessors, or perhaps the dependency trees that get mapped out between the various classes. Regardless, any simple edit of a VI is followed by 1 second or so of "busy" cursor during which the IDE locks up for recompiling etc. I've been dealing with this so long I hardly notice anymore, editing VIs just has a built in cadence where I make a change, wait, make a change, wait...

Build times for this application used to take about 45 minutes, but now that 2011 SP1 hit it managed to get down to 15 min or so. I have not noticed a large change in the "wait" duration from SP1 though.

Are you using the property node implementation of the read/write accessors? If so then I believe this slow down is what we have found and reported in CAR 313044 that is published in the known issues. This was a specific bug that wasn't a problem with the overall architecture.

I'll give a little bit more information on what Paul commented on about build time with classes (CAR 316145). With DSC installed we give the user the option of including custom I/O servers in a build. Right now the only way to see if there are custom I/O servers is to load any library within the project to see if it contains a custom I/O server. We were previously loading all libraries (e.g. classes and XControls) to check, only to unload them again. One simple quick workaround (if possible) is to deactivate DSC as we won't check for custom I/O servers if it isn't activated.

Hey Everyone,

This has been logged under CAR 305157. Thanks for reporting this.

For the record, the CAR for the issue I reported is 279298.

I also forgot to mention that I would especially like to use the property node accessor feature because I they don't look like VIs so it is quicker to see what is happening in the calling VIs....

Thanks for the Info Paul. We believe that the underlying solution to CAR 279298 is the same as CAR 255982. So when these bugs get fixed if there are any special instructions in the readme (possibly recompiling) about CAR 255982 you should apply them to CAR 279298 as well

FYI: Both of these should now show up in the LabVIEW Known Issues even if they are specific to RT.