3 ms·

This is a pretty amazing analysis that answers questions we probably all had as newbie programmers before realizing that code readability mattered more than eff

This is a pretty amazing analysis that answers questions we probably all had as newbie programmers before realizing that code readability mattered more than efficiency 99.9% of the time.

lmilcin 5y ago
In most applications you will not be able to get to the level of performance when any of this is going to matter. For example, if you program Python then there is so much more conditionals in Python runtime itself than you will not see any difference from couple of your conditionals being predicted better or worse. You will also be doing a lot of other stuff (like spending time in framework code, calling libraries, performing I/O) that will be making any gains from this pretty insignificant. Where this comes into picture is if you are really bent on improving performance of your code on a grand scale (when you develop algorithmic trading or maybe operating system), when you have a very dense, busy inner loop (for example video encoding) or when you develop compilers.
- andrepd 5y ago
  I think that's more of an indictment of how bad the concept of "production python" is.
  - mateo411 5y ago
    I disagree with that. Production doesn't mean that the code runs fast, but that it is stable and reliable. There are use cases where you need a performant system that uses CPU really efficiently, in these cases Python is probably not the right tool.
  - Dylan16807 5y ago
    Lots of code doesn't run so often that it needs to be optimal. If you use proper data structures and algorithms then you'll avoid the real problems. The constant factor slowdown you get from language choice won't matter for the vast majority of lines of code.
    - andrepd 5y ago
      This is given as an excuse to write sloppy code and then we get the bloated mess that is modern software and the modern web. Plus python has many problems besides performance.
      - Dylan16807 5y ago
        Sloppy code would be using the wrong data structures and algorithms. Sloppy code would be optimizing nothing at all. If you write things with good big O performance, for almost all of your lines of code you're done. It will perform fine. Bloated messes don't come from writing a bunch of business logic in python instead of C, not while processors are this many orders of magnitude faster than they used to be. They comes from layers and layers of abstractions, or doing things completely the wrong way.
        BenjiWiebe 5y ago
        But if you're processing 10's of thousands of records in an O(n) loop, it will still be 10's of thousands of times slower than processing a single record in that loop. i.e. having good big O still doesn't mean the code will be fast.
        Dylan16807 5y ago
        Are you saying this is a scenario where O(1) is possible? Then "good big O" is O(1). Code that is O(n) is a mistake. If you're saying the fastest method is O(n), then sure, no method can guarantee fast processing of the entire list. But that fact sure isn't python's fault!
- im3w1l 5y ago
  My takeaway was the opposite. You have a fairly generous budget of if's and code size if you use a low level language. But if you use a higher level language you could run into the limits.
  - chrisweekly 5y ago
    Bit of a tangent but in the userland app space I'm increasingly interested in sidestepping the whole "conditionals" question with finite state machines, eg with a lib like XState.
hinkley 5y ago
The goalposts are constantly changing, but there are refactorings that achieve both. As a student, real world performance analysis was one of the ways I kept myself engaged in otherwise sometimes tedious curricula. After college I landed a job far away from home only to discover their software was so slow I was embarrassed to be associated with it, so I got a quick self-directed study in practical optimization. On any given day, you're much more likely to be amused by your own cleverness than anyone else is, so you either do it for your own reasons, stop doing it entirely, or find palatable forms of expression. My most concrete example is probably the bizarre love triangle between locality of reference, lazy evaluation, and common subexpression elimination. There are several islands of sanity where reading comprehension is improved by refactoring in ways that happen to reduce or avoid calculations. You clean up the code and it gets 5% faster. You use the same pattern in three places and you're comfortably into double digits. As more evidence piled up for me about the dangers of confusing code, I spent more time thinking about the legibility and very little time thinking about the performance, but the fact is that I still do it intuitively. 25yo me would still be pretty happy with the performance of my code, even though <mumble>yo me gets a little concerned about that level of enthusiasm.
- parhaml 5y ago
  I appreciate this comment. We can develop these little ingrained patterns that keep things 'optimal' and at the same time think about future us having to read the code again. I know that even 1 week future me appreciates readable code at the expense of a _little_ bit of performance.
simias 5y ago
I agree of course but I'd argue that an array lookup would be more readable and more maintainable than this `if` soup in the `getCountry` example code. One added benefit for instance is that the language will never allow you to declare two values for the same index, whereas you could very easily mess up a copy/paste and forget to update the condition. More generally I don't think we should consider that readability and efficiency are at opposing ends of the same axis. With a bit of care and good tools it's often possible to get the best of both worlds, or close enough.
Agentlien 5y ago
This kind of statement always makes me feel funny. It's true that algorithmic complexity is the most important part, you always have to measure, and micro optimisations are often not worthwhile. But this type of statement seems a lot stronger than that. I'm a graphics programmer working in game development and most of my time is spent on our performance task force. I spend a lot of time thinking about the performance impact of things I write and revisiting things I've written to improve their performance. My job would have been easier if more people spent a bit more time considering the performance impact of their solutions, as well.
- jugg1es 5y ago
  Your job is very different than mine. Gaming/graphics are their own domain with different priorities. When your goal is to process data on the scale of several seconds, readability matters more. When your goal is performance per frame, you will definitely have different priorities.

This is a pretty amazing analysis that answers questions we probably all had as newbie programmers before realizing that code readability mattered more than efficiency 99.9% of the time.

lmilcin 5y ago

In most applications you will not be able to get to the level of performance when any of this is going to matter. For example, if you program Python then there is so much more conditionals in Python runtime itself than you will not see any difference from couple of your conditionals being predicted better or worse. You will also be doing a lot of other stuff (like spending time in framework code, calling libraries, performing I/O) that will be making any gains from this pretty insignificant. Where this comes into picture is if you are really bent on improving performance of your code on a grand scale (when you develop algorithmic trading or maybe operating system), when you have a very dense, busy inner loop (for example video encoding) or when you develop compilers.

andrepd 5y ago
I think that's more of an indictment of how bad the concept of "production python" is.
- mateo411 5y ago
  I disagree with that. Production doesn't mean that the code runs fast, but that it is stable and reliable. There are use cases where you need a performant system that uses CPU really efficiently, in these cases Python is probably not the right tool.
- Dylan16807 5y ago
  Lots of code doesn't run so often that it needs to be optimal. If you use proper data structures and algorithms then you'll avoid the real problems. The constant factor slowdown you get from language choice won't matter for the vast majority of lines of code.
  - andrepd 5y ago
    This is given as an excuse to write sloppy code and then we get the bloated mess that is modern software and the modern web. Plus python has many problems besides performance.
    - Dylan16807 5y ago
      Sloppy code would be using the wrong data structures and algorithms. Sloppy code would be optimizing nothing at all. If you write things with good big O performance, for almost all of your lines of code you're done. It will perform fine. Bloated messes don't come from writing a bunch of business logic in python instead of C, not while processors are this many orders of magnitude faster than they used to be. They comes from layers and layers of abstractions, or doing things completely the wrong way.
      - BenjiWiebe 5y ago
        But if you're processing 10's of thousands of records in an O(n) loop, it will still be 10's of thousands of times slower than processing a single record in that loop. i.e. having good big O still doesn't mean the code will be fast.
        Dylan16807 5y ago
        Are you saying this is a scenario where O(1) is possible? Then "good big O" is O(1). Code that is O(n) is a mistake. If you're saying the fastest method is O(n), then sure, no method can guarantee fast processing of the entire list. But that fact sure isn't python's fault!
im3w1l 5y ago
My takeaway was the opposite. You have a fairly generous budget of if's and code size if you use a low level language. But if you use a higher level language you could run into the limits.
- chrisweekly 5y ago
  Bit of a tangent but in the userland app space I'm increasingly interested in sidestepping the whole "conditionals" question with finite state machines, eg with a lib like XState.

hinkley 5y ago

The goalposts are constantly changing, but there are refactorings that achieve both. As a student, real world performance analysis was one of the ways I kept myself engaged in otherwise sometimes tedious curricula. After college I landed a job far away from home only to discover their software was so slow I was embarrassed to be associated with it, so I got a quick self-directed study in practical optimization. On any given day, you're much more likely to be amused by your own cleverness than anyone else is, so you either do it for your own reasons, stop doing it entirely, or find palatable forms of expression. My most concrete example is probably the bizarre love triangle between locality of reference, lazy evaluation, and common subexpression elimination. There are several islands of sanity where reading comprehension is improved by refactoring in ways that happen to reduce or avoid calculations. You clean up the code and it gets 5% faster. You use the same pattern in three places and you're comfortably into double digits. As more evidence piled up for me about the dangers of confusing code, I spent more time thinking about the legibility and very little time thinking about the performance, but the fact is that I still do it intuitively. 25yo me would still be pretty happy with the performance of my code, even though <mumble>yo me gets a little concerned about that level of enthusiasm.

parhaml 5y ago
I appreciate this comment. We can develop these little ingrained patterns that keep things 'optimal' and at the same time think about future us having to read the code again. I know that even 1 week future me appreciates readable code at the expense of a _little_ bit of performance.

simias 5y ago

I agree of course but I'd argue that an array lookup would be more readable and more maintainable than this `if` soup in the `getCountry` example code. One added benefit for instance is that the language will never allow you to declare two values for the same index, whereas you could very easily mess up a copy/paste and forget to update the condition. More generally I don't think we should consider that readability and efficiency are at opposing ends of the same axis. With a bit of care and good tools it's often possible to get the best of both worlds, or close enough.

Agentlien 5y ago

This kind of statement always makes me feel funny. It's true that algorithmic complexity is the most important part, you always have to measure, and micro optimisations are often not worthwhile. But this type of statement seems a lot stronger than that. I'm a graphics programmer working in game development and most of my time is spent on our performance task force. I spend a lot of time thinking about the performance impact of things I write and revisiting things I've written to improve their performance. My job would have been easier if more people spent a bit more time considering the performance impact of their solutions, as well.

jugg1es 5y ago
Your job is very different than mine. Gaming/graphics are their own domain with different priorities. When your goal is to process data on the scale of several seconds, readability matters more. When your goal is performance per frame, you will definitely have different priorities.