5 ms·

The article is interesting, but there's really no point making little micro-optimisations like this in Python (yes a 35% increase in speed to one small part of

The article is interesting, but there's really no point making little micro-optimisations like this in Python (yes a 35% increase in speed to one small part of your program is a micro-optimisation). If the code is really performance critical (by which I mean, the person running the program would notice a difference) then use a more suitable compiled language e.g. by calling into a C extension module like numpy. But, most of the time, making small performance tweaks will result in no noticable impact. Some optimisations in pure Python are genuinely worth it, but they're usually by using a totally different data structure to change the asymptotic complexity e.g. if you repeatedly use `x in foo` in a loop then it's worth making sure foo is a set rather than a list.

gpvos 5y ago
It all depends on context. They did write "[...] the 10% performance improvement was significant for the service that I was working on."
- IshKebab 5y ago
  Yes but his point is that if a 10% performance improvement is significant then you shouldn't be using Python!
  - dec0dedab0de 5y ago
    Sure, but if you can easily get that 10% improvement in your existing code, you probably should take advantage of the easy win. Even if you're eventually going to rewrite all or part of it in another language.
  - Joeboy 5y ago
    To me, it seems like there is potentially quite a good business case for writing l = [None] * 10_000 instead of rewriting parts of your application in C (possibly hiring new staff to do so).
    - IshKebab 5y ago
      Very short term maybe. Medium term you're just putting off work and building up technical debt.
  - HyprMusic 5y ago
    That's a very naive statement. In machine learning, for example, there's a lot of scenarios where performance isn't critical but due to the huge quantities of data you may need to process (especially during feature engineering or selection), micro optimisations like this can result in huge improvements over millions of iterations. Not to mention Python has Cython and numba's JIT which can provide great performance when needed.
  - deleted 5y ago
    [deleted]
  - rednafi 5y ago
    I was actually waiting for this comment to pop up. Unfortunately, it's not so black and white as it seems. The service in question is deeply coupled with a Django monolith and rewriting that will be mostly a waste of time for a medium scale business like us. However, micro-optimizations and effective refactoring quickly add up and for us, improving the service response by 100ms via micro-optimization is better than improving it by 200ms via rewriting the entire service.
    - quietbritishjim 5y ago
      200ms -> 100ms for a whole request (not just a tiny part of a request) is indeed worthwhile, I never meant to disagree with that. But for micro-optimisations, you'd be lucky to get a 10% speed increase in 10% of things you do, which would only give only a speed increase of 1% overall (obviously those are made up numbers to illustrate the idea). As I said in my first comment, usually the actual gains come from using a different data structures or making vectorised calls in to C libraries, and I assume that's what you mean by the effective refactorings in your case.
- quietbritishjim 5y ago
  I knew my comment would be a bit spicy for HN :-) Frankly, I'm skeptical that it actually was significant for them. IMO people grossly overestimate the utility of a 10% or even 20% increase in speed. (A 90% increase is probably worth the effort, while 50% is borderline.) If a user clicks on a button and it feels slow (e.g. 500ms), then it's still going to feel slow if you speed it up but it's still the same order of magnitude (e.g. 400ms). Roughly the same is true at all different levels e.g. if you speed things up from 5 hours to 4 hours then it's still long enough that it shapes your day. A similar point applies to hardware costs. And it's even more true if there's some absolute ceiling e.g. if you speed up your service by 20% so it doesn't overflow then you'll still be close to danger if conditions perturb slightly. And all the above is not even relevant to the article. It's talking about how to preallocate a list. There's no point doing that unless you then populate the list! In most situations that's going to dwarf the time to create the list object, and at the very least is likely to match it. So you're likely to be talking about a tiny fraction of an overall runtime.
- rednafi 5y ago
  Yep. Our entire stack is primarily based on Python. Rewriting microservices in a faster language seems tempting in theory but in practise there are so many hurdles that sometimes, in medium term, micro-optimizations really pay off.

gpvos 5y ago

It all depends on context. They did write "[...] the 10% performance improvement was significant for the service that I was working on."

IshKebab 5y ago
Yes but his point is that if a 10% performance improvement is significant then you shouldn't be using Python!
- dec0dedab0de 5y ago
  Sure, but if you can easily get that 10% improvement in your existing code, you probably should take advantage of the easy win. Even if you're eventually going to rewrite all or part of it in another language.
- Joeboy 5y ago
  To me, it seems like there is potentially quite a good business case for writing l = [None] * 10_000 instead of rewriting parts of your application in C (possibly hiring new staff to do so).
  - IshKebab 5y ago
    Very short term maybe. Medium term you're just putting off work and building up technical debt.
- HyprMusic 5y ago
  That's a very naive statement. In machine learning, for example, there's a lot of scenarios where performance isn't critical but due to the huge quantities of data you may need to process (especially during feature engineering or selection), micro optimisations like this can result in huge improvements over millions of iterations. Not to mention Python has Cython and numba's JIT which can provide great performance when needed.
- deleted 5y ago
  [deleted]
- rednafi 5y ago
  I was actually waiting for this comment to pop up. Unfortunately, it's not so black and white as it seems. The service in question is deeply coupled with a Django monolith and rewriting that will be mostly a waste of time for a medium scale business like us. However, micro-optimizations and effective refactoring quickly add up and for us, improving the service response by 100ms via micro-optimization is better than improving it by 200ms via rewriting the entire service.
  - quietbritishjim 5y ago
    200ms -> 100ms for a whole request (not just a tiny part of a request) is indeed worthwhile, I never meant to disagree with that. But for micro-optimisations, you'd be lucky to get a 10% speed increase in 10% of things you do, which would only give only a speed increase of 1% overall (obviously those are made up numbers to illustrate the idea). As I said in my first comment, usually the actual gains come from using a different data structures or making vectorised calls in to C libraries, and I assume that's what you mean by the effective refactorings in your case.
quietbritishjim 5y ago
I knew my comment would be a bit spicy for HN :-) Frankly, I'm skeptical that it actually was significant for them. IMO people grossly overestimate the utility of a 10% or even 20% increase in speed. (A 90% increase is probably worth the effort, while 50% is borderline.) If a user clicks on a button and it feels slow (e.g. 500ms), then it's still going to feel slow if you speed it up but it's still the same order of magnitude (e.g. 400ms). Roughly the same is true at all different levels e.g. if you speed things up from 5 hours to 4 hours then it's still long enough that it shapes your day. A similar point applies to hardware costs. And it's even more true if there's some absolute ceiling e.g. if you speed up your service by 20% so it doesn't overflow then you'll still be close to danger if conditions perturb slightly. And all the above is not even relevant to the article. It's talking about how to preallocate a list. There's no point doing that unless you then populate the list! In most situations that's going to dwarf the time to create the list object, and at the very least is likely to match it. So you're likely to be talking about a tiny fraction of an overall runtime.
rednafi 5y ago
Yep. Our entire stack is primarily based on Python. Rewriting microservices in a faster language seems tempting in theory but in practise there are so many hurdles that sometimes, in medium term, micro-optimizations really pay off.