LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of state machine with enum vs string?

Ummmm. OK. I guess... Yeah. 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 11 of 46
(2,952 Views)

@Steve Chandler wrote:


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? Smiley Happy


A few thoughts for you to ponder because I would look at this differently.

 



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

 

Sounds like a named queue and the "load instruction" state is more properly in the scope of the executive calling the shots rather than the worker bee (SM) whose poorly managed.


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 46
(2,947 Views)

@JÞB wrote:

A few thoughts for you to ponder because I would look at this differently.

 



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

 

Sounds like a named queue and the "load instruction" state is more properly in the scope of the executive calling the shots rather than the worker bee (SM) whose poorly managed.


 

The architecture might seem a little strange but it is totally about performance. Also the architecture is pretty well cast in stone. I literally cannot change it. That is outside my control.

=====================
LabVIEW 2012


0 Kudos
Message 13 of 46
(2,926 Views)

well we've all been there before (do it like this but make it work)

 

from raw performance an array of clusters of equal size will index much easier.  if the string is the only variable sized element in the cluster I would expect performance to improve by swapping it to a enum. 

 

But I haven't benchmarked it either.

 

As far as readability and write ability the case select tool does sound like a nice aid.  You can get some simillar benefits by using separators in the enum by adding dash and dash-dash and dash-dash-dash but that if far from ideal if you get a whole lot of cases.  (silly enum items editor does not support everything an enum can do)


"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 46
(2,917 Views)

I doubt the unbundles will hurt your performance. The compiler should take care of that for you and you should end up with the code under the hood doing a direct access to the desired data.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 15 of 46
(2,902 Views)

I did a quick benchmark and the enum wins as suspected. I attached the project in LV82 format but the numbers below are from running under LabVIEW 2011.

 

These numbers are how long in seconds it takes for 10 million calls to the different types of state machines. I also tested each with and without subroutine priority. The enum set for normal priority beats the string version running as a subroutine.

 

  • enum normal priority 1.965
  • enum subroutine priority 1.231
  • string normal priority 3.307
  • string subroutine priority 2.542

 

However I found another disadvantage in using the enums. If you have an array of enums constant it defaults to some particular width. You can resize the array elements so that you can see everything but as soon as you edit the typedef the width goes back to the default. Even if the typedef is strict and even if the array of the typedef is also a typedef.

 

Regardless of that the performance of an enum is so much better that I will have to live with these issues.

 

C:\Users\sdchandl\AppData\Local\Temp\Example_VI_BD.pngExample_VI_BD.pngExample_VI_BD.png

 

 

[Edit: I didn't mention that I am redoing this application. I started out with a nice object oriented approach. I was using the command pattern with dynamic dispatching selecting the states. Performance was absolutely aweful. I didn't mess around too much with changing accessors to be inline, turning off debugging, or changing the execution priority of the methods. There were just too many files to be keeping up with.]

=====================
LabVIEW 2012


Message 16 of 46
(2,901 Views)

Thanks for the benchmark, Steve. I have always been interested in it but never took the time to investigate. As a rule of thumb, I take from your benchmark that enums are about 2 times faster than strings.

 

On my computer (running LabVIEW 2010 SP1) enums and strings are not that much apart as on yours. Here is what I see:

 

  • enum normal priority 2.299
  • enum subroutine priority 1.372
  • string normal priority 2.891
  • string subroutine priority 2.023
0 Kudos
Message 17 of 46
(2,884 Views)

well the good news is my machine is about 7-10% faster than Steves-  right across the board nicely consistant with his numbers.

 

whatch the normal priority vis in the attachment- debugging was inadvertantly turned back on (for a 2x performance hit)


"Should be" isn't "Is" -Jay
0 Kudos
Message 18 of 46
(2,878 Views)

You can still squeeze that last bit of performance out of your state machine!  Smiley Very Happy

 

PyramidPower.png

 

Spoiler
The case structure actually does slow down with more than two choices.  The FN used to be faster, now LV optimizes the silly single iteration loop.

 

Message 19 of 46
(2,868 Views)

Ouch! Kind of reminds me of this Smiley Very Happy

 

 

=====================
LabVIEW 2012


Message 20 of 46
(2,865 Views)