Object proliferation vs storing as a flattened string

[cbutcher]

I'm looking to store some configuration information about measurement positions along with the location data in an array of 'Configuration-Position.lvclass' objects, or similar. Then, I can have 'Configuration.lvclass' which holds an array of these objects. My Configuration-Position class contains another class, which is a set of configuration values, and a cluster of X,Y,Z positions, along with a timestamp to tell me when I last acquired data there (possibly this will be removed).

I have no need for the configuration data when I'm not at a given measurement position. I can consider flattening the configuration data to a string, and storing that rather than the actual object in my Configuration-Position class objects, with a subVI to recreate an object using Unflatten from String when I access that position.

Is this a good way to move unused objects out of memory (and should I care?) or is this, to quote a post from LAVA, "foot shooting with a bazooka"?

[tyk007]

My opinion, in order, would be "Depends on the situation", "Probably not", "Most likely".

[nathand]

---

cbutcher wrote:

Is this a good way to move unused objects out of memory (and should I care?) or is this, to quote a post from LAVA, "foot shooting with a bazooka"?

---

Are you storing thousands of these objects? Do you have a reason to believe there's currently a problem? If not, I would let LabVIEW handle the memory management, and keep your code simple.

[cbutcher]

I'll probably have a few hundred of them, but I'm looking at ways to store a kind of configuration history so I was considering this as a possible tie-in.

However, I found that a class object can be written directly to a binary data file, so that simplifies storage quite a lot if I store them that way (and makes flattening to string less desirable) . I just need to work out how to store them such that I can say "what were the positions and settings for each position on the 12th May 2017" in June or similar and not have a horrible mess to unpick.

I feel like timestamping changes into a log should be possible but then I'll need a reference and if it's always just the previous point I could have to carry out a lot of overwrites to get to a given time's state. Perhaps storing a full state every day/week and then changes from the previous state one at a time back to the previous full state would at least prevent having to unwind the entire log.

[nathand · Accepted solution]

If you need a full version history of your settings, I would use a local version control system. For example, you can create a local mercurial repository for your configuration, and then call mercurial commands through System Exec (in LabVIEW) to get the version of the settings from a particular revision (and, with a bit more work, you can match revisions to dates by getting a list of all the revisions and parsing out the dates). Setting up the interface to the mercurial commands will be less work than trying to design your own system for tracking versions, plus if you ever need to back up the configuration to a remote repository later, adding that feature will be trivial.

[cbutcher]

I don't want to really open a can of worms with 'git vs mercurial', about which I have spent more than an hour reading now with almost no tangible differences beyond branching vs cloning/named-branches, but is the suggestion for hg based on your previous experience, better LabVIEW/System Exec integration, or just an example DVCS?

I'm already using git to track my LabVIEW code, but I use 'git bash' to do this, and so maybe it will be less trivial to connect to System Exec. My understanding (without trying) is that hg has better command-line interactions with Windows.

[nathand]

I mentioned mercurial only as an example; I haven't used git and I didn't want to suggest it without being certain of how it works. I'd use whichever system you're familiar or comfortable with, unless you find out that for some reason it doesn't support your use case.