Hacker News new | past | comments | ask | show | jobs | submit login

> If the implementation uses a form of jump-table then this [switch statement] has the benefit of giving you an O(1) performance based on the messages, whereas with the if-else-if chain, the commands will be checked and processed before status and errors.

The reason for using a switch statement in the first place was so that you'd have constant performance. The argument against the simple implementation was:

> Let’s assume in v2.0 of the system we want to extend the message set to include two new commands and one new status message ... the if-else-if version will handle the change without modification, whereas the existing switch statement treats the new commands still as errors.

Treating the new commands as errors is a feature of the switch statement style, not a problem. They need to be added to the jump table, not implemented with reduced performance.




Also using big O notation here makes no sense surely? The claim that the switch version is (in contrast) O(1) is not even wrong.


Yeah I'm not quite sure I understand this statement either. Does he mean that in the case of a command the first `if` passes and the rest are ignored, but in the case of status and error you need to perform the previous `if`s as well? So then the case for status is what, O(2)? That makes no sense.

If you're going to write something this obscure for the sake of "performance", you want to be damn sure it's worth it -- that performance is even an issue, and that this is a large enough improvement to justify not doing the simple thing.

Honestly it feels like the author wants to do it this way because it's clever, and the "performance" reason is just rationalising it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: