Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Caching a QD Plugin

Hi Darren

Do you have any thoughts on Caching a QD plugin?

Is it possible, how to do it, anything to watch out for etc...

I am trying to decrease load time (after first call) on a plugin that I would use a lot

The plugin is larger than a single VI (contains a few classes / libraries etc...) and I am wondering if I can & should? keep it in memory.

Cheers

-JG

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 1 of 19
(14,176 Views)

There is no easy way to do this in 2009, nor do I expect there to be in 2010.  Quick Drop (and whatever plugin you called) completely leaves memory after each use.  I can investigate coming up with some mechanism in 2011 that would keep it around in memory (which would improve launch performance of Quick Drop), at which point, it would be pretty easy to add a plugins cache.  I would probably also want to add some way to clear the cache, as it is very helpful when debugging a new plugin to have any changes be immediately testable just by launching the plugin again.

-D

Message 2 of 19
(8,207 Views)

Yes, having something like Tools » Clear Quick Drop Cache would also allow us to continue to add plug-ins dynamically without restarting the development environment.  Having QD launch faster would be huge enhancement (today, when I'm hasty, the procedure is Ctrl-Space, Type, Oops, Backspace, Re-type, Drop).


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 3 of 19
(8,207 Views)

Thanks Darren.

It would be a nice IMO to be able to have an option to cache QD onload (LabVIEW) or on-first-call.

Is there a way to make this onto your 2011 feature list - including your suggestions above?

In the meantime is there anything I can do for my plugin?

As you said no easy way - so I am guessing there is a way?

Thanks

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 4 of 19
(8,207 Views)

I found a little time today to take a stab at this.  My findings are posted here:

A "Cached" QDKS Plugin

-D

0 Kudos
Message 5 of 19
(8,207 Views)

Hi Darren

Thanks heaps for looking at this. I used your suggestions and added caching to my LVOOP Theme Creator to test it.

I had the issue of References leaving memory when the launcher exited to I had to handshake the Process with the Launcher (using a Notifier) to avoid errors.

I also had a the SHIFT + HOTKEY function spare so I use that to unload the plugin.

Here is the Launcher code:

Cache.png

However, I did not get the performance boost I was after - I seem to get it in source but not the deployed instance running as a QDP.

Do you have any suggestions for improving the code?

Kind regards

-JG

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 6 of 19
(8,207 Views)

I don't have easy access to LabVIEW right now, so I can only guess based on your screenshot...can you try using Open VI Reference with the spawned VI name as a string input (like I did in my example code), as opposed to your current approach with the Static VI Reference?  I've seen strange behavior in the past with Static VI Reference...what ends up getting loaded, the lifetime of VIs in memory, etc...I usually play it safe with Open VI Reference.

-D

0 Kudos
Message 7 of 19
(8,207 Views)

Thanks Darren.

Ok,it seems that issue was the a FP Close call taking the VI out of memory - so it was not being cache'd each time (hence the no different in speed comment). Sorry about that.

My issue now, seems to be how to pass a valid refnum from the VI being QD'd on (the refnum available through your QDP interface) to the cache'd VI.

This is what is happening:

When the plugin is called for the first time the plugin works fine as expected and it gets cached.

When the plugin the second time (now from the cache), I can't seem to get a valid reference to the QD'd VI e.g. I get error 1055 when I pass it to a VI Server method.

I unload the plugin, then the next call works fine!

So if it gets launched by the same VI that passes it the VI reference (as it does on first call) everything works fine.

Do QD Plugins run in different Application Instances each time??

So when it is called again it doesn't like it?

I will be the first to admit I am not full bottle on Application Instanaces (and how QD does it) etc...

Any ideas will be appreciated tho.

Cheers

-JG

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 8 of 19
(8,207 Views)

If any one has any ideas wrt to handling VI References in different Application Instances in the problem above - please post!

Cheers

-JG

Certified LabVIEW Architect * LabVIEW Champion
0 Kudos
Message 9 of 19
(8,207 Views)

Monday and Tuesday were NI holidays, so I haven't been in the office.  I will be on Wednesday, though.  Can you email me (my first name and last name separated by a dot, at ni.com) a sample plugin that demonstrates the issue you're having with the VI reference, so I can take a look?

-D

0 Kudos
Message 10 of 19
(8,207 Views)