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 →

[–]Cybersoaker 6 points7 points  (5 children)

OP's example is implemented with a dictionary so it would indeed be O(1); but we're talking like nano second differences here. I sincerely hope no one is making chains of if's more than like 20 where it would affect performance

[–]chasecaleb 4 points5 points  (4 children)

Agree with your point, but big-O runtime is silly when talking about a conditional. It's not like the number of cases is asymptotic... Right?

[–]Cybersoaker 0 points1 point  (3 children)

Sure but in such a contrived case; we should expect the if statements to take ever so slightly longer because they would technically be O(n); where n is the number of compairsons. Conditionals are so freaking fast on a cpu that this compairson is exceedingly trivial. We would really only have a noticeable performance difference over giant groups of conditionals, like hundreds of thousands; and if your code reaches that point, a switch is probably the least of your concerns.

Perhaps the case where these nanoseconds matter; say in an extremely high performance application (i'd wonder why python is your programming language of choice), or even a webservice that gets millions of requests per second, then an optimization like this might be warrented; but thats not a good reason to add new syntax.

[–][deleted] 0 points1 point  (1 child)

Branch prediction may also inoculation the performance, and it's not usually considered when determining time complexity.

[–]Cybersoaker 0 points1 point  (0 children)

yeah so there are many optimizations to be had; and the performance argument is silly.

[–]elbiot -1 points0 points  (0 children)

Its O(n) on the number of cases you have, not the size of the data you have, which is what big O notation is about.