Rube Goldberg Code

[JÞB]

@CA The reuse library gets divorced from source around these parts.  

Guess what I'm getting paid to do.

@W, benchmark it against anyone's code but Christian's 

[Hooovahh]

---

@JÞB wrote:

@W, benchmark it against anyone's code but Christian's 

---

No need to benchmark Christian's solution, test the two solutions you've already provided and you'll see the non property node method is somewhere around 50 times faster than the enabled case using a property node.  There are of course improvements that can be made.

Oh and removing the write property helps but the non property method is still about 20 or 30 times faster than the single read.

[JÞB]

---

@Hooovahh wrote:

---

@JÞB wrote:

@W, benchmark it against anyone's code but Christian's 

---

Oh and removing the write property helps but the non property method is still about 20 or 30 times faster than the single read.

---

With or without the FP in memory?

[Hooovahh]

Calling it as an inlined subVI, with the front panel closed, taking time stamp information after reading control values, and stopping the time stamp before writing back to the indicators.  Thread swapping is really what kills a property node speed.

[JÞB]

---

@Hooovahh wrote:

Calling it as an inlined subVI, with the front panel closed, taking time stamp information after reading control values, and stopping the time stamp before writing back to the indicators.  Thread swapping is really what kills a property node speed.

---

That is not what I expected from a p-node property that does not load the FP into memory on an inlined chunk.

I (possibly incorrectly,) assumed that the conversion from 
"Bytes" to "String to send to the transfer buffer for display to the user"

would be rather finely optomized

[JÞB]

Then of course I caught this gem

Spoiler

[altenbach]

---

@JÞB wrote:

---

That is not what I expected from a p-node property that does not load the FP into memory on an inlined chunk.

---

On a side note, this would still be a useful idea. 😄

[JÞB]

I think the size of the disable structure says enough

[altenbach]

Seen here

So we have many cases of a state machine, and every single state is indicated by a particular pattern of three booleans.

Apparently, some think they need to place separate instances of local variables for all three indicators in every single case, and to keep things clean, the terminals should be outside, completely disconnected from the code.

(further comments are in my reply in the thread linked above)

[Ben]

---

@altenbach wrote:

Seen here

So we have many cases of a state machine, and every single state is indicated by a particular pattern of three booleans.

Apparently, some think they need to place separate instances of local variables for all three indicators in every single case, and to keep things clean, the terminals should be outside, completely disconnected from the code.

(further comments are in my reply in the thread linked above)

---

I can rationalize that (but not justify). When you modify the state machine and add another case (to the non-type-def'd enum) you can just right click and choose "duplicate case". If using locals the duplication creates more locals. If using the actual control, the controls will be duplicated.

Ben