Slow VIT Loading

[wwbrown]

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?

[Jim Kring]

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.

[Adnan]

+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.

[wwbrown]

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.

[Jim Kring]

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".

[wwbrown]

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?

[Jim Kring]

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.

[wwbrown]

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?

[Jim Kring]

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.

[crelf]

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?

[Jim Kring]

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.

[crelf]

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.

[Jim Kring]

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.

[crelf]

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...