LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Delay when applying large, hierarchical type definitions

Hello,

 

I searched around using various terms, but couldn't readily find posts on what I'm experiencing.

 

Has anyone else noticed huge delays when applying large, hierarchical type definitions?  I've got about a dozen nested type definitions of clusters, each containing anywhere from 10 to 100 controls, and they're used throughout a large application.  When I open any member of that hierarchy, make a small change, and hit apply, I see the hourglass (spinning ring of death in Vista/7) for a good two to five minutes.

 

A short term workaround has been to close all dependent VIs and typedefs, and then make an isolated edit.  Then, if I open the whole application again, I see some compiling taking place, but it seems to take a lot less time than when the whole application is open.

 

I could have sworn that I read a discussion by some others commiserating about this at some point, but now I can't find it.

 

Has this been addressed, and has anyone heard if there's any development effort to improve this?

 

Thanks,

 

Jim

0 Kudos
Message 1 of 6
(2,965 Views)

Hi Jim,

 

I was able to find an earlier report of this issue. It seems the behavior is because when the type definition is updated, all referencing VIs will recompile automatically. If your application is large, and the typedef is used in a large number of VIs, it's not dissimilar to mass compiling with every change.

 

It's not ideal, but there are a few workarounds other than you mentioned. You could use more specific typedefs and not a massive one to pass data through VIs. Or you could pass a queue reference to the subVIs and have the queue be made of of elements that are the large type definition.

 

If this is causing major problems, let me know, and I'll pass along your concerns to R&D.

All the best,

Fred Visser -- SystemLink R&D -- National Instruments
Message 2 of 6
(2,941 Views)
Hi Fred, Thanks for getting back to me on this. > You could use more specific typedefs and not a massive one to pass data through VIs. It's funny, I've actually adopted using larger typdefs in the last year or two for architectural simplicity, and that's when I've noticed this becoming a problem. In fact, for what it's worth, right now I'm using a data reference to store the "data dictionary" (large typedef) but that doesn't really help the issue. From an architectural sense, it makes things easier for me because I have much fewer wires to pass around most of my data is in one place. > Or you could pass a queue reference to the subVIs and have the queue be made of of elements that are the large type definition. Actually, I'm using a data reference right now, which is somewhat analogous to what you're suggesting. (Maybe not? I also use queues and notifiers depending on the situation.) I haven't really seen this technique help the issue; I'm still noticing the large delays, but only when editing the typedefs. The only way I've really found relief is to separate the large typedef into smaller ones and pass them around separately. This is kind of a pain because it means I have many more references to data structures to keep track of. > If this is causing major problems, let me know, and I'll pass along your concerns to R&D. Actually, if I'm to be honest, it really is starting to become a hassle. I hit apply and end up working on something else for a few minutes while the compiler chugs away. I'd be really interested in an improvement in this area. If it makes things easier, I can discuss this via email and upload an application I'm working on as an example. (Multiple large apps I'm working on exhibit this behavior) Thanks again for your help. Regards, Jim
0 Kudos
Message 3 of 6
(2,934 Views)

Wow... how the line feeds got removed from that message is beyond me.  Sorry about the tough format for reading...

0 Kudos
Message 4 of 6
(2,925 Views)

Hi Jim,

 

Could I get you to create a Service Request, and request that it be directed to me? This will be the easiest way to accept your code, and attach that request to a CAR for R&D.

Thanks,

Fred Visser -- SystemLink R&D -- National Instruments
Message 5 of 6
(2,891 Views)

Fred, I am uploading my code and have submitted a support request.  The reference number is 7305441, and I am still in the process of uploading via FTP.

 

I'm very grateful for your diligence in helping me with this.

 

Kind regards,

 

Jim

0 Kudos
Message 6 of 6
(2,874 Views)