State machine performance woes in .NET
-
This is a followup to a thread started in the Lounge: The Lounge[^] First this makes me think of The First Law Of Optimization: Don't do it! And then The Second Law of Optimzation: If you have to do it, don't do it yet! This obvuiouly refers to peephole optimzation. Selecting an algorithm of lower complexity is a different matter. But worrying about how the switch construct is handled by the compiler falls in the peephole class. When I programmed Pascal around 1980, the compiler knew a single way of coding CASE x OF statements: As a jump table with at most 256 entries. Or more exactly: Alternatives was limited to internal values 0..255. Fair enough for small student exercises, but for real code, it was just tooo limiting. Then I got into CHILL with its decision table entries ("CASE A, B, C OF ...", with all combinations of A, B, C values, with "don't care" and ELSE and the whole works - but still static). Later comes C# with much greater flexibility. Bottom line: Tiny jump tables is a very special case. You may hope for the compiler to optimize for that particular one, but I wouldn't spend too much energy on it. In the world of modern code, it is just too special. Then there is another thing, now that you refer to state machines: I don't believe that switch statements is a good way to implemnent state machines. Maintenance is resource demanding when you expand it with new states and events. Giving proper handling to illegal events is difficult. And any reasonably complete state machine, e.g. for a communication protocol, will have a rather sparse state table. If you implement a sparse 2D transition table by a jump table for one dimension, each leading to a jump table in the other dimension, you implemenent that full, sparse table in a rather un-maintainable way. I would rather pack the table, and address it as a single table. So you would maintain the table in an unpacked form, and use a small compaction routine to build the runtime table when you change it. I let the compaction routine generate the table access function as well, so that a simple table not requiring e.g. predicate handling for alternate actions will not have this access code generated. I guess my code is not super-optimized to those tiny demo-examples to teach students the
-
This is a followup to a thread started in the Lounge: The Lounge[^] First this makes me think of The First Law Of Optimization: Don't do it! And then The Second Law of Optimzation: If you have to do it, don't do it yet! This obvuiouly refers to peephole optimzation. Selecting an algorithm of lower complexity is a different matter. But worrying about how the switch construct is handled by the compiler falls in the peephole class. When I programmed Pascal around 1980, the compiler knew a single way of coding CASE x OF statements: As a jump table with at most 256 entries. Or more exactly: Alternatives was limited to internal values 0..255. Fair enough for small student exercises, but for real code, it was just tooo limiting. Then I got into CHILL with its decision table entries ("CASE A, B, C OF ...", with all combinations of A, B, C values, with "don't care" and ELSE and the whole works - but still static). Later comes C# with much greater flexibility. Bottom line: Tiny jump tables is a very special case. You may hope for the compiler to optimize for that particular one, but I wouldn't spend too much energy on it. In the world of modern code, it is just too special. Then there is another thing, now that you refer to state machines: I don't believe that switch statements is a good way to implemnent state machines. Maintenance is resource demanding when you expand it with new states and events. Giving proper handling to illegal events is difficult. And any reasonably complete state machine, e.g. for a communication protocol, will have a rather sparse state table. If you implement a sparse 2D transition table by a jump table for one dimension, each leading to a jump table in the other dimension, you implemenent that full, sparse table in a rather un-maintainable way. I would rather pack the table, and address it as a single table. So you would maintain the table in an unpacked form, and use a small compaction routine to build the runtime table when you change it. I let the compaction routine generate the table access function as well, so that a simple table not requiring e.g. predicate handling for alternate actions will not have this access code generated. I guess my code is not super-optimized to those tiny demo-examples to teach students the
F-ES Sitecore wrote in the Lounge:
CBA doing any research, but I don't think .net actually supports the switch statement, it is just syntactic sugar, your switch statement is converted to an "if\else" block by the compiler.
Is there any decent compiler around that treats all different variations on switch (/CASE) in exactly the same manner? Even 40 years ago, when I learned CHILL - from the guy developing the CHILL compiler - did we learn about how the compiler considered various code generating alternatives, from simple jump tables up to if/else sequences as a last resort. The choice was significantly affected by the compiler options selected, whether to optimize for small code space, small data space, fastest execution etc. This was done 40 years ago. I am sure that compiler developers have not abandoned such options.
-
F-ES Sitecore wrote in the Lounge:
CBA doing any research, but I don't think .net actually supports the switch statement, it is just syntactic sugar, your switch statement is converted to an "if\else" block by the compiler.
Is there any decent compiler around that treats all different variations on switch (/CASE) in exactly the same manner? Even 40 years ago, when I learned CHILL - from the guy developing the CHILL compiler - did we learn about how the compiler considered various code generating alternatives, from simple jump tables up to if/else sequences as a last resort. The choice was significantly affected by the compiler options selected, whether to optimize for small code space, small data space, fastest execution etc. This was done 40 years ago. I am sure that compiler developers have not abandoned such options.
Using my own two eyes, and my personal experience, I have never seen it as anything but an if\else statement. I appreciate there probably are variances, maybe ones I didn't realise were originally switch statements, but from what I've seen the .net compiler seems to heavily favour the if\else. This convo is a lot like people arguing that god exists....they swear it does, but all I'm asking is for actual simple proof :D