Same Run-Time Class

[mje]

I have a case where I need to determine at run-time if two objects are of the same class. There's obviously no built in way to do this and a quick search turns up nothing, so here's what I came up with:

 

 

This isn't much of big deal, but when I was testing it I wanted to make sure the VI didn't produce data copies due to the wire splits, so I created a test where I give A and B a data payload. The good news is it seems the VI doesn't produce any data copies. The bad news is my test VI has double the memory usage I expected, so I'm missing some fundamental understanding of how buffers are working here.

 

Attached is the sample project. As configured, two Vehicle objects are created (be it a Vehicle proper or any of three distinct Vehicle implementations), each is loaded with a 100 MB payload. After running the Test.vi uses 400 MB of data space. Any one have an idea why? None of the objects are being sent to indicators so I'm not looking at buffers related to the UI.

 

 

A few comments: If LabVIEW is creating copies at the coercion of the wires to Same Runtime Class.vi I'd expect those copies to vanish if the empty subdiagram is enabled, but this does not happen. If you just flat out delete the subdiagram the VI uses no memory because LabVIEW seems to be smart enough to realize you never need the buffer data.

Same Class 2012.zip

[Stobber]

AristosQueue worked on the team that wrote that node (or wrote it himself). I would ask him.

[Daklu]

I don't pretend to understand LV's memory management, so take this with a grain of salt. 

 

In the Same Runtime Class vi instead of branching the input wires I wired a LVObject to the top connector on the PRTC prim.  It still used twice as much memory as I expected.  I interpret that as pointing to something inside the PRTC prim.

 

I reverted that change, made a few other changes, and built an executable.  Monitoring memory consumption while running the executable revealed this:

 

Assuming 100 MB per class,

1. If the input classes are the same 400 MB are used.

2. If the input classes are siblings 200 MB are used.

3. If one input class is Vehicle and another is a child, 300 MB are used.

 

It appears the PRTC prim allocates memory for a copy of the input object in cases where the preserve operation is successful.

Same Class_Dak.zip

[mje]

Nice investigation, Daklu. I bet this is related to that trick AQ posted some time ago using sequential casting primitives which eventually landed in the Actor Framework templates. I'll do some digging and try some tweaks next time I'm at a workstation.

[Yair]

Without going into the details of the allocations, I will just point you to the following thread, which you may find familiar - http://lavag.org/topic/15354-testing-for-the-same-class/

 

And note that regardless of AQ's performance trick (which can be found at http://lavag.org/topic/15135-performance-tweak-for-lv-classes-and-to-more-specific-node/ ), using the default value of the class there was more efficient. I don't know if that changed in 2012.

[mje]

Hah! That is too funny. And looking back at that thread I'm running back to the same flaw in the same library I ran into a year ago. I guess you can say it never got fixed. That's the thing about "don't do it right, do it now" solutions-- they keep coming back to bite you.

That's it, fool me twice. Time to fix that framework, testing for class equivalence never was the right way to do it anyway.

[Daklu]

I nominate Yair as the Lava historian.  He seems to remember every discussion ever had and comes up with links to them.

[Testy]

Couldn't you use two Get LV Class Path.vi's and compare the outputs for equality?

[Daklu]

Yes, you can.  I've done that in the past.  IIRC there is a significant performance hit with the Get LV Class Path vi.  It's probably a non-issue for the occasional comparison but could be noticable if you're doing a lot of comparisons.

 

------------

 

[Edit]

Alternatively, if you're working with a predefined set of classes you can give each class a constant identifier and compare those.  It's not as useful as a generalized class comparison vi but it can be used in a pinch.

[Yair]

mje, just so we're clear, did you try the method I suggested in reply 10 of the other thread (get the default objects and do the casting on them)? Did it help with the memory allocations?

[mje]

Negative, I could not get a version which did not produce copies-- using the base project above I always ended up with 400 MB of data space on the Test.vi after running.

 

To be fair though, I haven't given it much thought. I'm reworking my framework because testing for exact classes is in no conceivable way the right way of doing things. Especially since this is the second time the same flaw has come up, it's time to refactor.