memory vs speed vs ease of use

[J.Mamakos]

I'm sure this has been discussed many times before, for instance the old clear as mud thread and the more recent nugget on the same topic, but I was hoping for some confirmation for my particular case.

I am currently constructing a multi-plot XYGraph from a 'super-cluster' in a particular manner which is easy to add data to, but seems a bit convoluted to update.  So I thought of arranging the data in the cluster in a different way, which makes it very easy to update the graph but a little more long-winded to update the data. (see VI for details)

I then constructed a timing setup to try and work out if one way was considerably faster than the other or not.  However it seems that the timing outputs aren't completely consistent. I was wondering if someone could point out what I'm doing wrong?  (Also, I noticed a general performance hit when I added in the Diagram Disable Structures. Is this expected?)

In addition to how fast each things executes (okay, Im' not dealing with huge arrays, but I was still curious), I want to bear in mind how easy it is to use each method in my project code.  Is one way necessarily better than the other from a design point of view?  The big clusters to the left were taken from the project I'm building, but had all the non-essential arrays emptied.

So, as in the title, which method is better in terms of memory usage, speed, and ease of use (or best practice), and what may be wrong with my timing setup to produce slightly inconsistent results?

Picture of BD:

Spoiler

Thank you.

- James

P.S. Apologies for the large BD size. I wrote this in a hurry!

[SteveChandler]

You didn't attach the controls. Anyway the timing will never be consistent unless you are using Real Time. You should look into LVOOP - it's just clusters and VIs that can access the clusters. Check out the composition pattern. That means you have a class that contains other classes as it's data. This is analogous to a cluster of clusters.

[GerdW]

Hi J,

general notes:

- don't do speed measurements for parallel running loops

- in the lower loop you could use the InPlace structure. It may help for "ease of use" as well as speed and memory... (Instead of IndexArray/ReplaceArraySubset combination and also instead of Unbundle/Bundle combination!)

[Mark_Yedinak]

---

@Steve Chandler wrote:

You should look into LVOOP - it's just clusters and VIs that can access the clusters.

---

Boy do I hate when people say this. Object oriented programming is a bit more than that. While at it's simplest definition an object is the "data and the methods that act on that data" the power of OOP comes from how classes are defined, what your inheritance is and how well you keep things decoupled. An analogy would be to say a building is just a bunch of materials all put together. You might be able to hobble something together but the results can be disastrous if not done right.

[SteveChandler]

LVOOP is a big mystery to many people. I think that by telling them that it is really just a cluster with VIs that can access that cluster is a good introduction. Starting out by talking about inheritance, dynamic dispatch, scope and the various design patterns trends to leave people with a blank stare. I hate it when people introduce the subject by talking about how a cat is a mammal. Introductary material is usually too abstract.

But absolutely it is important to learn about propor design! Telling people that it is a cluster and VIs that can access that cluster makes their eyes light up. Hopefully it leads them down the OOP path. I always recommend "The Object Oriented Thought Process" for learning what OOP is really about.

[J.Mamakos]

---

@Steve Chandler wrote:

You didn't attach the controls. Anyway the timing will never be consistent unless you are using Real Time. You should look into LVOOP - it's just clusters and VIs that can access the clusters. Check out the composition pattern. That means you have a class that contains other classes as it's data. This is analogous to a cluster of clusters.

---

1. What controls weren't attached? There's only one control (Number of runs) and that's wired up.
2. I used the Tick Count (ms) primitive because that's what Ben had used in his original post, but I see a different looking object in the community nugget. Is this the Real Time primitive you speak of? And is it available in LV8.5 (I couldn't find it when I had a search through the pallets)?  Failing that, I found a Timed Sequence structure in my pallet that looks a bit like a code-drop express vi; should I just use this instead of trying to make my own?

---

@GerdW wrote:

Hi J,

general notes:

- don't do speed measurements for parallel running loops

- in the lower loop you could use the InPlace structure. It may help for "ease of use" as well as speed and memory... (Instead of IndexArray/ReplaceArraySubset combination and also instead of Unbundle/Bundle combination!)

---

1. There are no parallel loops (see the little blue wire going from the right (output) of the top structure to the left (input) of the bottom structure to make them execute one after the other.
2. I've had a read in the LV help about the In Place Element Structure, and will see how well it works in this example. Now that I know about this structure, I can think of several places it might be of use elsewhere in my project so thanks for pointing it out to me!

I've been having a read through of various help files and some online documentation about LVOOP, but am not entirely sure what I could actually use it for.  The LV examples weren't particularly helpful in that respect (or maybe I was looking in the wrong place).  I have had some experience of MatLAB's object-oriented programming styles, and I picked LabVIEW up fairly quick.  Maybe I'll be able to get my head round LVOOP too.

[drjdpowell]

---

@Mark_Yedinak wrote:

An analogy would be to say a building is just a bunch of materials all put together. You might be able to hobble something together but the results can be disastrous if not done right.

---

But it's better to start by building a shed then by trying to build a skyscraper.  Like Steve, I recommend people start by just using LVOOP as a nice clean way of doing typedef clusters plus VIs that operate on those clusters, with benefits like wizards to create new VIs and pretty wires.  Then appreciate the key advantage that the cluster can be passed around by anyone but only unbundled by it's own methods.  Then try a very basic parent-child thing (a simulated instrument driver, say).  Work your way up.  

-- James

[SteveChandler]

J.Mamakos, the VI was broken. When I listed errors, it said thee were three missing controls. I didn't see them on the block diagram or front isabel. When I double clicked in the error window it hilighted an empty area at the top of the code. There was nothing there. Sorry but I am on my phone and don't remember the names of them. Just put the VI in an empty project and look at the dependencies.

[J.Mamakos]

---

@Steve Chandler wrote:
J.Mamakos, the VI was broken. When I listed errors, it said thee were three missing controls. I didn't see them on the block diagram or front isabel. When I double clicked in the error window it hilighted an empty area at the top of the code. There was nothing there. Sorry but I am on my phone and don't remember the names of them. Just put the VI in an empty project and look at the dependencies.

---

Ah, it was trying to link to a couple of type def controls from which some of the constants had originally been derived. Sorry for my confusion; it hadn't occured to me that they were even still linked!

Attached is a .zip file of the vi and the three controls.

P.S.  That Timed Sequence structure I found actually looks a bit complicated!  I'd still like to get this hand-made one working better, though.

P.P.S.  The In Place Element Structure seems useful so far, though I can't tell if it speeds things up at all.