Jump to content

Slow VIT Loading


Recommended Posts

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?

Link to comment
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.

Link to comment
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.

Link to comment
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".

Link to comment
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.

Link to comment
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?

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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...

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.