Jump to content

Using LV Class vs Passing Cluster


Recommended Posts

The LV Class feature has some nice control and privacy aspects compared to the age-old method of simply passing around a TypeDef'd Cluster. More specifically, I like how the Class data cannot be unbundled outside of the Class VI members. Here is an attempt to measure the extra overhead associated with the LV Class. Basically I just measured how long it took to perform 100,000 write-read cyles on a single member of the data type. This test was repeated for both the 'Cluster' and Class method.

Conclusion: Cluster method is always faster. For extremely simple data types, the cluster method (on my PC) is twice as fast. I did an example of a very complicated data type and the cluster method was 1.5 times faster.

Link to comment

QUOTE(jfazekas @ Feb 6 2008, 05:04 PM)

Conclusion: Cluster method is always faster. For extremely simple data types, the cluster method (on my PC) is twice as fast. I did an example of a very complicated data type and the cluster method was 1.5 times faster.

Thats not bad. I thought it would be much slower.

Seems proper to make the tradeoff if data privacy and protection is high on the priority list.

Link to comment

QUOTE(Aristos Queue @ Feb 6 2008, 12:51 PM)

If you edit "Write Boolean.vi" and turn off dynamic dispatch on the terminals, you'll get times equivalent to the cluster. :ninja:

Curious. Would someone else please test the following for me... I'd like to make sure the following is repeatable...

Open the "Test Main.vi". Run it and get the test time for LVClasses. Mine was around 12 msec.

Now edit "LV Test Class.lvclass:Write Boolean.vi" to turn of dynamic dispatching.

Run the test again. This time I got 35-40 msec.

Save everything. Run the test. Still 35-40 msec.

Close the project and reopen. Run the test again. This time I got 5-6 msec, which is the same as the time for clusters.

I don't have a clue why the delay is in there if you've edited the conpane of the VI. Very strange. If others can replicate then I'll file the CAR.

Link to comment

QUOTE(Aristos Queue @ Feb 6 2008, 03:06 PM)

Curious. Would someone else please test the following for me... I'd like to make sure the following is repeatable...

My results: (note: I ran this in a VM, so the results might be a little skewed?)

Open the "Test Main.vi". Run it and get the test time for LVClasses. Mine was around 57 msec.

Now edit "LV Test Class.lvclass:Write Boolean.vi" to turn of dynamic dispatching.

Run the test again. This time I got 20-40 msec.

Save everything. Run the test. Still 20-40 msec.

Close the project and reopen. Run the test again. This time I got 10 msec, which is the same as the time for clusters.

Link to comment

QUOTE(Aristos Queue @ Feb 6 2008, 09:06 PM)

Curious. Would someone else please test the following for me... I'd like to make sure the following is repeatable...

Open the "Test Main.vi". Run it and get the test time for LVClasses. Mine was around 12 msec.

Now edit "LV Test Class.lvclass:Write Boolean.vi" to turn of dynamic dispatching.

Run the test again. This time I got 35-40 msec.

Save everything. Run the test. Still 35-40 msec.

Close the project and reopen. Run the test again. This time I got 5-6 msec, which is the same as the time for clusters.

I don't have a clue why the delay is in there if you've edited the conpane of the VI. Very strange. If others can replicate then I'll file the CAR.

Hello,

I ran the test without change :

- cluster ~17msec

- class ~27msec

Turned out the dynamic dispatch on "write boolean.vi", saved the project, re-ran (no close and re-open) :

- cluster ~17msec

- class ~17msec

Can you explain roughly what the dynamic dispatch is ? Or post a link to some documentation about it.

Thanks

Link to comment

QUOTE(TiT @ Feb 6 2008, 10:19 PM)

Can you explain roughly what the dynamic dispatch is ? Or post a link to some documentation about it.

I'm certainly not the most qualified to post on this, but.....

Dynamic dispatch means that the ACTUAL code being called is dependent on the CLASS of the object being passed to it. The default method (VI) in the parent class must be overridden in a child class. If a child is passed, the child VI is called. If a parent is passed, the parent VI is called. The "choice" is determined at run-time if I'm not mistaken.

Shane.

Link to comment

Just a note to everyone regarding time measurements. Run enough iterations so that the times measured are at least 1 second.

If you are running just a few cycles I find that the state machine overhead makes up significant portion of the time measurement.

I'll post what I find regarding the dispatch terminals. Thanks for the input.

Link to comment

1- I noticed the same thing with Dynamic Dispatch...

2- I added a "byReference" comparison to jfazekas's VIs and I end up with a ten-fold decrease in speed... :headbang:

Is it to be expected or I completely missed the point of byReference architecture? I would have thought it to be quite comparable. Anyone has a benchmark on that?

Download File:post-10515-1202338932.zip

Link to comment

QUOTE(normandinf @ Feb 6 2008, 05:11 PM)

2- I added a "byReference" comparison to jfazekas's VIs and I end up with a ten-fold decrease in speed... :headbang:

Is it to be expected or I completely missed the point of byReference architecture?

Yes, it is to be expected. I don't know what factor you should expect, but it will definitely be slower. By ref means that LV can't do any inplaceness optimization, means there has to be synchronization overhead even when no read/write conflict even exists. The cardinal rule of LV: If you want performance DON'T BREAK THE DATAFLOW.
Link to comment
  • 4 weeks later...

Hi,

I see similar speedups after removing dynamic dispatch.

Another strange thing is that as soon as I open the project in LV 8.5 on Mac OS 10.5.2 one CPU core is 100% busy. No VI open just the project window. No change after recompiling, doing another "Save All", LV restart. Just opening the project automatically marks it as edited (Reason: "An attribute of the project was changed.")

Enough playing with LV and hanging out at LAVA for me tonight :ninja:

I´ll try it on WinXP at the office later this week.

Link to comment
  • 2 years later...

Earlier in this thread, I highlighted a performance problem that I found when trying the test VIs Gotz originally posted. I generated a CAR from that. That CAR finally made it to the top of the priority heap. And, like so many before it, it is being closed as user error. Only this time, the user is me.

If you turn off dynamic dispatching, you should indeed achieve essentially the same speeds between classes and clusters.

However, if you leave the front panel in memory, you'll take the performance hit of updating the panel controls/indicators. So when you modify the VI to turn off dynamic dispatching, make sure that you close the front panel of the Write Boolean VI and then do File >> Save All before you run the performance test again.

  • Like 1
Link to comment

What a coincidence--I've recently been wondering about the cost of boxing/unboxing native types in classes versus clusters. Thanks for reviving the thread and the update on the bug.

However, if you leave the front panel in memory, you'll take the performance hit of updating the panel controls/indicators. So when you modify the VI to turn off dynamic dispatching, make sure that you close the front panel of the Write Boolean VI and then do File >> Save All before you run the performance test again.

This comment brings to mind a couple questions...

1. My understanding was that, in memory, a vi's code exists in the front panel and the block diagram is simply a visual representation of the code. That's why we can't close the front panel window but keep the block diagram open. In other words, having the vi loaded by definition means the front panel is loaded. If the accessor method is being used in the test code, isn't it loaded into memory regardless of whether the front panel is open?

2. I take it Save All does a memory sweep and removes those things that are not needed at the moment? Would we get a different outcome if we were to save (not Save All) and close the front panel of each vi individually? Is it valid to consider Save All as a 'soft reset' of sorts, meaning it puts the dev environment memory in the same state as if we had closed LV and reopened it with all the same FPs and BDs visible? (I'm thinking of memory state as what is loaded, not where it is loaded, which obviously would probably change if LV were restarted.) Does Save All behave have a different effect if selected from the project window versus an individual vi? (I'd assume not, but you never know...)

Link to comment
In other words, having the vi loaded by definition means the front panel is loaded.
No.
I take it Save All does a memory sweep and removes those things that are not needed at the moment?
No.

A) A VI's code block is not in either the panel or the diagram. It is a separate piece entirely. The panel is not necessarily loaded with a VI. It is loaded for a top-level VI, but subVIs will not load their panels until they are needed unless something in their VI Properties or block diagram indicates that the panel will always be needed. Examples are configuring the VI as a dialog VI in Appearance or having a statically linked property/invoke/reference node on the diagram.

B) The panel can be in memory even when not open.

C) Reasons for the panel to be in memory include a statically bound control property/invoke node on the diagram, a static control reference node on the diagram, a dynamically opened control reference existing in memory... or the VI could just have unsaved changes, in which case the panel stays in memory.

D) If the panel is in memory, for any reason, running the VI takes time to update the controls/indicators on the panel.

E) Save will unload the panel if the only reason it had for staying in memory is that it had unsaved changes. You shouldn't think of Save as a way to "fix bugs in LV where LV forgot to unload something." It just clears one of the reasons the panel might be hanging around, and if that's the only reason, it unloads. Obviously if the window is still open, it won't unload.

F) It doesn't matter how you invoke save -- File >> Save, Save All, Save All This Project, programmatic save -- all of these will check to see if the panel can now leave memory.

Link to comment

However, if you leave the front panel in memory, you'll take the performance hit of updating the panel controls/indicators. So when you modify the VI to turn off dynamic dispatching, make sure that you close the front panel of the Write Boolean VI and then do File >> Save All before you run the performance test again.

Hang on a sec, so if I have a vi with only class object controls and indicators and leave the FP open, I take a performance hit updating the controls and indicators that don't change appearance by one RGB value of one pixel ?! Ouch.

Link to comment

Hang on a sec, so if I have a vi with only class object controls and indicators and leave the FP open, I take a performance hit updating the controls and indicators that don't change appearance by one RGB value of one pixel ?! Ouch.

It obviously still makes a copy of the data to the FP Object (rather than being related to a graphical update) just like any other.

Link to comment

It obviously still makes a copy of the data to the FP Object (rather than being related to a graphical update) just like any other.

Yes, but Why? I mean, I can see why FP controls that change their appearance need a copy of their data, but if the control doesn't change appearance why does the FP control need any data at all (other than type information obviously !) ?

Actually that might be an interesting idea for debugging dynamic dispatch calls - if the FP controls and inducators changed appearance depending on the runtime type of object they were being passed. Then there'd be a good reason to pay for getting a copy of the data....

Link to comment

Yes, but Why? I mean, I can see why FP controls that change their appearance need a copy of their data, but if the control doesn't change appearance why does the FP control need any data at all (other than type information obviously !) ?

Actually that might be an interesting idea for debugging dynamic dispatch calls - if the FP controls and inducators changed appearance depending on the runtime type of object they were being passed. Then there'd be a good reason to pay for getting a copy of the data....

Sure, you can't see it update in this case, but is still allocated memory e.g. to give you the option to cut and paste the data etc...

post-10325-0-29094700-1296170819_thumb.p

Link to comment

A) A VI's code block is not in either the panel or the diagram. It is a separate piece entirely.

Ahh... that explains a lot of my confusion with load behavior over the years. Thanks.

(Just to clarify, we are talking about the source code block, right?)

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.