Performance of state machine with enum vs string?

[SteveChandler]

I am laying out the groundwork for a very large state machine. It will have about 60 to 100 states. I kind of want to use an enum for selecting the states for convenience. But then if I use a string I can use Jim Carmody's case select tool so that wins out in convenience in one respect.

One concern about using a string is performance. Since an enum is just an integer wouldn't the selections perform better? I need to squeeze out every ounce of performance and in fact this state machine will be set for subroutine priority. Another concern that I have about a typedef enum is that I have heard something about the possibility of them getting "out of sync" between VIs when you edit them. Is there some way to avoid that, such as making sure all VIs that use this typedef are in memory when editing it?

[Ben]

Your gut feel about performance betwen the two approach is one that I share but have no eveidence to confirm or rule it out.

A benchmark should be preformed to compare the two methods (but you know that) and i would be very interested in if our shared suspicion is true.

So not being able to comment on that aspect of your question, I am curious about your decision to create a State machine with that many states. Can't it be implemented as as SM's within SM's ?

Curious,

Ben

[PhillipBrooks]

I'm not sure that a large state machine and a subroutine priority are going to work.

Selecting subroutine will disable the front panel and debugging capability, preclude use of asynchronous nodes such as VISA or queues and all subvis called must also be subroutine (including LabVIEW native functions written as VIs).

[SteveChandler]

Thanks Ben, I will benchmark a simple state machine using an enum vs string and post the results here. I was hoping that someone could give me a definitive answer so I wouldn't have to go through the trouble. It will make a good nugget if the performance is greatly different.

As for the number of states, I am pretty sure that it has to be one state machine. I'm afraid I cannot give a lot of details.

Phillip, I am aware of the requirements for subroutine priority. This will not show it's front panel and will not do any IO. I will only set it to subroutine after debuging and testing it. It will only use a few inlined subVIs that I will write and I know those will also have to be subroutine VIs.

One more thing. The state machine has about ten shift registers for internal data. I do not want to use a cluster for the internal data because of performance concerns. I don't want the overhead of bundling and unbundling in the states.

[soupy]

a single cluster for all of your data will work just fine as long as you labview is never forced to copy it (the inplace structure is your friend). use the "show buffer allocations..." tool to find the copies.

bundling/unbundling will not hurt your performance. It is pretty much the fastest operation labview has.

[SteveChandler]

Awesome! I know about the inplace structure but for some reason it never occured to me to use it here.

But even though cluster access is among the fastest operations available, it still has to do something. As I said I want every possible ounce of performance that is possible. But maybe using the inplace element structure gives the same effect as using individual shift registers?

[soupy]

play with the "show buffer allocation..." tool and you'll see how much it doesn't do. you can unbundle down multiple levels, and index out data without ever making a copy. you're simply pointing labview to the data you need.

note that, in this case, your code will take up more screen space, but it will actually be much, much faster. screen size != speed!

I use this method for our super-fast, super-featured hispeed daq system and performance has never been an issue. 

[Ben]

---

@Steve Chandler wrote:

....

As for the number of states, I am pretty sure that it has to be one state machine. I'm afraid I cannot give a lot of details.

...

---

I am having trouble figuring out the "has to" part.

See this thread for designs I have posted previously.

In this SM

please look the section that is entered from "Change Request 8 " can take multiple paths but all ends at "Stop Monitoring? 15". I could have implemented that as a sub-SM and it would have reduced the number of state required for that part of the work from five to one.

Any time I see "single entry, fan out, merge" I think sub-SM.

This could also help with your shift register as well because (again seea bove) the bulk of the ose states deal with Logging so rather than use a SR, put what would have been in the SR (file path or ref) to be used there OR possibly an AE that can be used in each of those states.

So I still don't understand why sub-SM aren't a possiblity.

Trying to help,

Ben 

[PhillipBrooks]

---

@Steve Chandler wrote:

This will not show it's front panel and will not do any IO. I will only set it to subroutine after debuging and testing it. It will only use a few inlined subVIs that I will write and I know those will also have to be subroutine VIs.

One more thing. The state machine has about ten shift registers for internal data. I do not want to use a cluster for the internal data because of performance concerns. I don't want the overhead of bundling and unbundling in the states.

---

Re: string vs. enum:

Will the caller of this VI be specifying the state as an input, or will the state be determined internally based upon other input data?

If the state is to be explicitly specified on each call, I would probably use a typdefed enum rather than a string, but that's just me...

[SteveChandler]

---

PhillipBrooks wrote:

Will the caller of this VI be specifying the state as an input, or will the state be determined internally based upon other input data?

If the state is to be explicitly specified on each call, I would probably use a typdefed enum rather than a string, but that's just me...

---

Inside the state machine there is an array of a cluter containing an array of states that I will call "instructions". Each instruction is an array of states. These are what I am trying to decide on using an enum or a string for. The instructions array is loaded into a shift register on initialization. The contents of this array never changes inside the state machine.

There is a state called "load instruction" that takes an integer input from outside this VI which indexes the "instructions" array, unbundles the array of states, and loads that array into another shift register. It sets an integer shift register that I will call "instruction step counter" to zero. The state machine iterates through the array of states by incrementing the instruction step counter and indexing the next step. The final step in each instruction is the load instruction state and the cycle continues.

Weird enough?