wwbrown Posted March 21, 2006 Report Share Posted March 21, 2006 Has anyone else noticed the degradation in VIT load time over LV7. I have a large application that starts a number of VITs as part of a class implementation for 10 power supplies. It takes an order of magnitude longer - less than a second under LV7 versus 10-15 seconds now. Has anyone heard of a workaround? Quote Link to comment
Jim Kring Posted March 21, 2006 Report Share Posted March 21, 2006 Has anyone else noticed the degradation in VIT load time over LV7. I have a large application that starts a number of VITs as part of a class implementation for 10 power supplies. It takes an order of magnitude longer - less than a second under LV7 versus 10-15 seconds now. Has anyone heard of a workaround? Have you noticed a different between the development environment and the run-time engine (built EXE)? I think I noticed a significant improvement in built EXEs. Quote Link to comment
Adnan Posted March 21, 2006 Report Share Posted March 21, 2006 +1 Same problem. It seems LabVIEW reload all subVIs each time we create an instance of VIT (even if the subVIs are in memory). The only workaround, we've found is to use Reentrant VI technique instead of VIT instanciation. Quote Link to comment
wwbrown Posted March 21, 2006 Author Report Share Posted March 21, 2006 Have you noticed a different between the development environment and the run-time engine (built EXE)? I think I noticed a significant improvement in built EXEs. I have not tried the .exe approach, but I am not optimistic. My classes are "active" classes (they are top-level and have a meaningful front panel), so use of re-entrant VIs is not an option. Quote Link to comment
Jim Kring Posted March 21, 2006 Report Share Posted March 21, 2006 I have not tried the .exe approach, but I am not optimistic. My classes are "active" classes (they are top-level and have a meaningful front panel), so use of re-entrant VIs is not an option. In LabVIEW 8.0, each instance of a reentrant VI has its own front panel and debuggable block diagram. These are referred to as "clones". Quote Link to comment
wwbrown Posted March 21, 2006 Author Report Share Posted March 21, 2006 In LabVIEW 8.0, each instance of a reentrant VI has its own front panel and debuggable block diagram. These are referred to as "clones". Thanks Jim - I was unaware of this new feature in LV8. Does this mean there is no longer any reason to use a VIT? Quote Link to comment
Jim Kring Posted March 21, 2006 Report Share Posted March 21, 2006 Thanks Jim - I was unaware of this new feature in LV8. Does this mean there is no longer any reason to use a VIT? I can't think of any reasons to use the VIT technique. Personally, I did not like it, due to the requirement that the VIT cannot be in memory when it is instanciated. This means that you cannot statically link to it in your application, which makes dependency management in stand-alone application builds more complicated and error prone. Quote Link to comment
wwbrown Posted March 21, 2006 Author Report Share Posted March 21, 2006 I can't think of any reasons to use the VIT technique. Personally, I did not like it, due to the requirement that the VIT cannot be in memory when it is instanciated. This means that you cannot statically link to it in your application, which makes dependency management in stand-alone application builds more complicated and error prone. I never liked it either. I needed it for some active classes (top-level, with FP) implemented with your openGOOP model under 7.1. By the way, have you tried dqGOOP? Quote Link to comment
Jim Kring Posted March 21, 2006 Report Share Posted March 21, 2006 By the way, have you tried dqGOOP? Yes, I've seen and used the queue data store technique. Mark Balla has put in some effort refactoring OpenGOOP to use the queue data store. I'm not sure when this will be released, but it will happen. Quote Link to comment
crelf Posted March 22, 2006 Report Share Posted March 22, 2006 Yes, I've seen and used the queue data store technique. Mark Balla has put in some effort refactoring OpenGOOP to use the queue data store. I'm not sure when this will be released, but it will happen. Personally, I'm a big fan of GOOP using queues (I'd implemented my own version prior to the dqGOOP release, but the dq version is a lot cleaned than mine) - it's easy, fast and covers a lot of what I need to do (I'm certainly not a GOOP 'power' user). I'd sure welcome an openG version (is there any legal issues here? Can OpenG release an open under LGPL that's very similar to the dq version?) Does anyone have any ideas of what's under the LabVIEW OO engine (soon to be realeased)? Is it going to be queue based, or something else entirely? Quote Link to comment
Jim Kring Posted March 23, 2006 Report Share Posted March 23, 2006 Personally, I'm a big fan of GOOP using queues (I'd implemented my own version prior to the dqGOOP release, but the dq version is a lot cleaned than mine) - it's easy, fast and covers a lot of what I need to do (I'm certainly not a GOOP 'power' user). I'd sure welcome an openG version (is there any legal issues here? Can OpenG release an open under LGPL that's very similar to the dq version?)Does anyone have any ideas of what's under the LabVIEW OO engine (soon to be realeased)? Is it going to be queue based, or something else entirely? As you mentioned, dq was not the first to use queues for GOOP. And, the author has stated publically that it is a combination of ideas mentioned first elsewhere. Quote Link to comment
crelf Posted March 23, 2006 Report Share Posted March 23, 2006 As you mentioned, dq was not the first to use queues for GOOP. And, the author has stated publically that it is a combination of ideas mentioned first elsewhere. Sure - there's nothing new in dqGOOP, but it's a particularly eloquent implementation of it - and also a IMHO great place for those unfamiliar with OO to start understanding the concept. Quote Link to comment
Jim Kring Posted March 23, 2006 Report Share Posted March 23, 2006 Sure - there's nothing new in dqGOOP, but it's a particularly eloquent implementation of it - and also a IMHO great place for those unfamiliar with OO to start understanding the concept. Sorry, I should have been more explicit. I was not trying to detract from dqGOOP -- I was just answering your question about whether OpenG, or anyone else, could legally use a similar implementation. IMO, a pure G GOOP implementation is best if it is open. Stay tuned, interesting things to come. Quote Link to comment
crelf Posted March 23, 2006 Report Share Posted March 23, 2006 Sorry, I should have been more explicit. I was not trying to detract from dqGOOP -- I was just answering your question about whether OpenG, or anyone else, could legally use a similar implementation. IMO, a pure G GOOP implementation is best if it is open. Stay tuned, interesting things to come. Ahh - gotcha. Staying tuned with great interest... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.