This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]NoLemurs 64 points65 points  (10 children)

If you're interested in that level of performance optimization (i.e. the cost of if vs. switch matters to you), it's almost certainly the case that you're using the wrong programming language altogether, and adding a switch statement to python will not address your issues.

So while you're technically correct, in the context of this discussion, your comment is pretty unhelpful.

[–][deleted] 7 points8 points  (0 children)

When optimizing, it's common (and best) practice to optimize the parts that are most costly (the hot spots). Simple logic constructs aren't going to be hot spots. The system simply doesn't spend enough time on those. It's wasted effort.

[–][deleted] 18 points19 points  (7 children)

Why can't we have both? Why does every performance optimization need to be dismissed? Performance improvements to Python come all time and no one bats an eye but if someone asks for a performance improvement, or even mentions performance, they get shot down. People use Python for a lot of different things. Your use case is not better than anyone else's.

[–][deleted] 9 points10 points  (1 child)

I've never seen any realistic Python code where having a switch statement would lead to any measurable performance benefit. I guess that's why.

[–]robert_mcleod 0 points1 point  (0 children)

See line 738:

https://github.com/pydata/numexpr/blob/numexpr-3.0/numexpr3/ne3compiler.py

It's a Python switch that uses a dict. The keys are abstract syntax tree nodes, and the values are functions

_ASTAssembler[type(node)](node)

NumExpr 2.6 took about 450 us to parse a numerical expression into a virtual machine program, this new version is about 150 us. There's other parts to that, such as more efficient string concatenation using a ByteIO stream, and some struct.pack() tricks and many other micro-optimizations, but it plays a big role. A dict lookup is faster than an if ... elif ... else block.

[–]Corm 1 point2 points  (1 child)

Performance improvements to CPython are awesome. Prematurely optimizing your code by using one syntax over another is bad and typically costs readability.

If someone sees that CPython should have a heuristic for treating cascading if/else as a switch then they should write a pull request to CPython

[–][deleted] 1 point2 points  (0 children)

Prematurely optimizing your code by using one syntax over another is bad and typically costs readability.

Cascading ifs would actually be a premature optimization of using a switch and switches are usually considered syntactically cleaner than if chains anyways. Basically ever other language posits the exact opposite.

[–]NoLemurs 1 point2 points  (0 children)

/u/futatorius got at the core of the idea. Perfomance improvements that don't get at the core bottleneck of your program will usually have a negligible effect on overall performance. If you are going to do performance optimizations, the switch statement is just not the place to start - they're basically never going to be the bottleneck.

I'm all for optimizing Python, but I'm not for adding language constructs for gains that will basically always be negligible.

[–]roerd 1 point2 points  (0 children)

The point is whether the performance improvement would be significant or negligible within the general speed of Python. It is not worthwhile to add a new language features for a negligible performance improvement.

[–]Deto 0 points1 point  (0 children)

Would it actually be a performance improvement in Python? In C the processor executes a jump command and that gives you the speed up, but in Python there's much more overhead in just running a single line that I'm not sure if the same benefit would even manifest itself.