Aristos Queue

So... there is a bug in LabVIEW. It has to do with NaN.
 
When there are two objects in memory, LabVIEW compares them, just like it does any other type. But there's a small performance cheat -- if the two objects are from the same memory address, the function returns TRUE -- they are equal. But that's not true if the class could contain a NaN. So we need to eliminate the performance check. This is why your comparison against the tunnel value directly gave different results than the other two comparisons.
 
What threw me off was some of your comments about how these should be equal and the subVI wasn't giving the same results as the caller. Here's a couple tidbits that might help your understanding of the issue.
 
a) NaN compares false when compared against itself and true for not equal.
b) SubVI isn't going to show its results because you've got it marked as inline. The VI that you're looking at never executes so the panel never updates. That accounts for the difference between the caller and the subVI. Turn off inlining and you'll see the panel update.
c) Compare Agg vs Compare Elt does not affect classes. Classes are defined as scalar values. Their internal implementation is opaque to external callers of the class. A class containing NaN compared against itself will always say it is not equal (so the Not Equal prim will return true). [barring the bug mentioned above.]

You have over a million open DVRs at the same time? Let me guess... 1,048,576 open refnums? Isn't that a rather suspicious number... a power of 2. Hmm...
 
This simple VI will fail after exactly 1,048,576 iterations:

 
 
 
LabVIEW uses a rather clever algorithm to allocate DVRs (or any refnum kind) in such a way to EFFICIENTLY support this trick: you can allocate a DVR, release it, and then allocate a new one, and you won't get the same refnum, which means that your other threads that might still be holding onto that old refnum will get errors about the refnum having been disposed instead of messing with the new refnum. 
 
I haven't dug into all the details of the algorithm, but the result is that you can only have 1,048,576 refnums of the same type open at any given time. After that, we can't allocate more until you free some -- you'll still get a unique refnum when you do this. 
 
So, that's the way it works. Congratulations... you're the first user in 15 years I've ever heard complain about this --- I hadn't had to dig into this before now. 
 
 
So... 
 
> I've recently run into problems with an application that creates a lot of objects.
 
That's "by-reference objects." Can I ask why you have all your objects as refnums? What application do you have that requires that sort of architecture? 
 
Let me clarify my question...
 
>  I'd much rather use U32 as a type for that array than a 1kB cluster with the actual results.
 
If your array is an array of objects, then the top-level array size will be pointer sized... on a 64-bit system, that's a U64.