Accessing private data with variant is very slow

[twols]

I am trying to understand, why is changing the variant is slower, if it is a private variable of a class and how can I fix it.

If setting the attributes directly, the operation of 1000 items takes only about 4 ms.

Extracting the part with variant access into a subvi causes a slow down to 1000 ms. Inlining this sub VI speeds up to about 7 ms.

The same procedure through a class method takes about 1100 ms, quite the same as non-inline-subVI.

But as long as it is not possible to make class methods inline, the access through a class will be that slow?

(Example below: Run Testbench.vi)

[AndreasKr]

Hi, 

as you already mentioned the inlined version speeds up the VI execution,

which is unfortunately not possible for class methods.

Do you want to use OOP in your project and this combined with the variant type?

Could you describe in detail what you have to do in your LabVIEW project?

Thanks a lot.

Andreas K

NI Germany

[codeman]

I did some experimenting and the additional overhead that you're seeing with the class implementation seems to be related to the dynamic dispatch class VIs (GetValue.vi and SetValue.vi).  Each time one of these dynamic dispatch functions is called, there is overhead associated with determining the correct class implementation.  If these functions don't need different implementations in child classes, then you should make them static dispatch instead.  Doing so makes the timing comparable to your variant implementation. 

[twols]

I'm using variant based dictionaries to store the configuration parameters for our simulation service tool. Using those dictionaries instead of clusters brings a lot of flexibility (and unfortunately higher execution time).

There are two speed ups I've figured out so far: Using static dispatch for class methods (I don't know if LV is kind of serializing and deserializing variant data when using dynamic dispatch) and changing the execution priority of the method vi to subroutine.

[Matthew_Kelton]

There are a few issues here.

1. You need to make sure your benchmarks are always comparable.  Your class test doesn't perform all the tasks your variant test does.  You can't make any real comparisons here.  This doesn't fix the timing issue, but in general, you need to make sure you perform the same tasks.  I modified the read VI to do a similar task as your variant test does.
2. You have no issue in your set.  Deleting the second for loops in both test yeild similar times.  When you start seeing issues like this, you need to start breaking the test VIs apart to know where the issue lies.
3. The issue is in the second loop and is more a compiler/LabVIEW issue with your benchmark.  I have attached an updated set of code.  In your class test, using a shift register for the class on the second for loop fixed the issue on my system.  There was minimal time increase.  I imagine there is someodd memory issue going on with your orginal benchmark test.
4. I also see no significant difference on my system whether your variant VI is inline or not.