Leaderboard

I use variant attributes quite a bit when I have a list of data which is both large (be it element size or number of elements) and dynamic (regularly adding/removing elements). This is ideal if access is primarily random, where I access some arbitrary elements at any given time. From time to time though, I must use sequential access where I need to enumerate every element. There is no native way to index variant attributes, so as far as I can tell we're left with one of two ways to do the enumeration. One: This is a bad way of doing it, as it involves returning an array of all objects as variants, converting it to the proper type, then operating on each element. Memory consumption becomes dominated by the size of data contained in the attributes. When running the VI with 100 MB of data (1000 attributes each 100 kB in size), the VI uses just over 100 MB of memory. Two: This is a much better way of doing it, involving accessing each element individually. Reduces memory consumption since we're not operating on the large values array, the footprint is dominated by the size of the largest element. Running the same case as above shows memory consumption of just over 100 kB. Nice. Turns out it also runs faster than the previous code as well (about 2/3 the time). But there's still a problem here. We're allocating an entire array of names. This can be verified if we redo the tests using large name strings as well. Using the same as above, 1000 attributes each with 100 kB values, but this time each name is also 100 kB in size, the memory footprints change to approximately 200 and 100 MB respectively. That is the second method still requires a lot of memory by virtue of the array of names it must use to operate. While the above situation is largely academic (screw 128-bit GUIDs, I'm going with 819200-bit ones!), it can come into play if your lists are large by virtue of the number of elements (opposed to the size of elements). In this case method "One" might prove the better way of doing it. I guess what I'm really going for is it would be good if there were a way to index variant attributes. YES, I know if you regularly need to enumerate your attributes you're doing it wrong, but there are some uses which you can't get away from. Serialization comes to mind. Any thoughts on this? I'll probably take this over to the idea exchange in a bit, just wanted to seed some discussion first. Attached is some code I played with to get the numbers above. Includes the two snippet VIs above, and a third one which generates variants for them to operate on. WARNING: running the test with the "Long Names" method continuously while collecting metrics can make the IDE unstable due to memory spikes if the default values are used. Close out your "real" work first! Regards, -michael AttributeEnumeration.zip

But true decoupling in a software architecture sense is only achieved in this real-world example if your new boss knows you exist but does not know what you do or how or how much you earn. In a software world, 100% decoupling is not achievable without having two completely independent pieces of software. As soon as both rely on a common interface (messagine protocol) there is inherently a certain amount of coupling present. So in a real-world sense I think the discussion about "full" decoupling is a discussion without any merit unless it's purely rhetoric. Even sharing data structures introduces a certain level of coupling between two modules. As with server up-time, squeezing the last few fractions of a percent of perfection (decoupling vs up-time) requires exponentially more effort. 99% decoupled software costs a WHOLE lot more time and effort to program than a 90% decoupled software in the same manner as a 99% reliability of a server is in a different ball park to 90% reliability. When it comes to decoupling, there are ONLY grey areas. Just my take. Shane. PS Here's a cool qoute from Wikipedia on the subject: "No couplingModules do not communicate at all with one another."

Simple: Disable the "Allow user to Close" setting in the VI settings dialog. More Involved: Add the VI->Panel Close? filter event to your event structure and pass TRUE to discard, but terminate your event handling loop anyhow to return to the caller.