3 ms·

And this is one of the problems with "optimize later". If you have a large project in Python, for example, far too often there isn't any one spot that has mass

And this is one of the problems with "optimize later". If you have a large project in Python, for example, far too often there isn't any one spot that has massive gains if you translate it to C. It's the death of a thousand cuts.

easytiger 12y ago
What are you talking about?
- to3m 12y ago
  (At a guess...) It's related, I think, to the standard piece of received wisdom, that you shouldn't optimize until some unspecified "later". This isn't a bad rule of thumb, but efficiency and convenience aren't always happy bedfellows, and, when coding, people tend to choose convenience. The result can be that when this later date arrives, and you go to make the code run more quickly, you're a bit stuck, because it would require changes more sweeping than can be accommodated with the resources available. But had performance been taken into account from the start, the changes would have been easy to make, or the whole thing might not even have been an issue. An example might be writing a compute-heavy program in python rather than C. Another standard piece of received wisdom is that once you get to optimize later, you'll just run the profiler and there'll be some hot spot due to poor choice of algorithm. So you optimize that bit and then you're done. But in practice this happens quite rarely; it's more common for the code to just be generally slow. A common reason it's generally slow is because performance wasn't considered during development, so the end result is the same. This is what the reference to translating into C relates to, I suspect - the idea that in your slow python program there's this one bit that can be turned into C and suddenly your program is super fast. (Of course, for many programs, python's speed is irrelevant. And any compute-heavy python program is likely only to be improved by translation into C - though your average python program would probably be much harder to make any quicker. Maybe that just goes to show that you actually have to think about this stuff on a case-by-case basis rather than relying on received wisdom. Anyway, I pick python only because it was mentioned.) Belief in the improve-algorithm-later theory usually causes people to dismiss micro-optimizations as pointless, because rather than get 0.1% here and 0.1% there you can just put it off until later and then get 25% all in one go. But this attitude actually makes it more likely that the code will paint itself into a corner, leaving micro-optimizations the only option. There isn't really any good quick easy solution to any of this, which is why I always liked it when computers got faster every year :(
ben0x539 12y ago
Optimizing later, after three major releases and a ton of minor ones, and after getting deployed basically everywhere, seems to be working out pretty well for them though?
- TheLoneWolfling 12y ago
  Only because it is designed in such a way to allow for it. The problem is architectural issues, which are far too often glossed over.
  - joesb 12y ago
    You don't know which optimization require which architecture. And your "extensible, optimizable architecture" may be the cause of the performance problem.
mikeash 12y ago
You will still typically achieve a better result (take less time building the software, produce software that works better and runs faster) if you "optimize later" than if you try to make everything fast from day one.
sauere 12y ago
Python might not be the fastest player on the block... but the increase in coding productivity will more than pay for extra equiptment to handle and speed-shortcomings.
- ramidarigaz 12y ago
  Except when it doesn't. I'm facing this problem with an embedded-ish project I'm working on where Python initially seemed like a good choice, but now we're regretting it for both performance and power usage reasons. If we'd gone with C or C++ initially we'd be having a much easier time optimizing. Not that I'm implying Python is bad, but if your target use case doesn't allow for a desktop or server, think carefully about what tech you use.
- pjmlp 12y ago
  Also achievable in JVM, .NET, ML family, Lisp family, Julia, D, Rust, Dylan with the added benefit of performance. I can't really envision using it for anything other than scripting.
sitkack 12y ago
If the application is properly decomposed into distinct subsystems one could take an entire subsystem and move it into C/Rust or Julia. Esp so if those subsystems are functionally pure.

easytiger 12y ago

What are you talking about?

to3m 12y ago
(At a guess...) It's related, I think, to the standard piece of received wisdom, that you shouldn't optimize until some unspecified "later". This isn't a bad rule of thumb, but efficiency and convenience aren't always happy bedfellows, and, when coding, people tend to choose convenience. The result can be that when this later date arrives, and you go to make the code run more quickly, you're a bit stuck, because it would require changes more sweeping than can be accommodated with the resources available. But had performance been taken into account from the start, the changes would have been easy to make, or the whole thing might not even have been an issue. An example might be writing a compute-heavy program in python rather than C. Another standard piece of received wisdom is that once you get to optimize later, you'll just run the profiler and there'll be some hot spot due to poor choice of algorithm. So you optimize that bit and then you're done. But in practice this happens quite rarely; it's more common for the code to just be generally slow. A common reason it's generally slow is because performance wasn't considered during development, so the end result is the same. This is what the reference to translating into C relates to, I suspect - the idea that in your slow python program there's this one bit that can be turned into C and suddenly your program is super fast. (Of course, for many programs, python's speed is irrelevant. And any compute-heavy python program is likely only to be improved by translation into C - though your average python program would probably be much harder to make any quicker. Maybe that just goes to show that you actually have to think about this stuff on a case-by-case basis rather than relying on received wisdom. Anyway, I pick python only because it was mentioned.) Belief in the improve-algorithm-later theory usually causes people to dismiss micro-optimizations as pointless, because rather than get 0.1% here and 0.1% there you can just put it off until later and then get 25% all in one go. But this attitude actually makes it more likely that the code will paint itself into a corner, leaving micro-optimizations the only option. There isn't really any good quick easy solution to any of this, which is why I always liked it when computers got faster every year :(

ben0x539 12y ago

Optimizing later, after three major releases and a ton of minor ones, and after getting deployed basically everywhere, seems to be working out pretty well for them though?

TheLoneWolfling 12y ago
Only because it is designed in such a way to allow for it. The problem is architectural issues, which are far too often glossed over.
- joesb 12y ago
  You don't know which optimization require which architecture. And your "extensible, optimizable architecture" may be the cause of the performance problem.

mikeash 12y ago

You will still typically achieve a better result (take less time building the software, produce software that works better and runs faster) if you "optimize later" than if you try to make everything fast from day one.

sauere 12y ago

Python might not be the fastest player on the block... but the increase in coding productivity will more than pay for extra equiptment to handle and speed-shortcomings.

ramidarigaz 12y ago
Except when it doesn't. I'm facing this problem with an embedded-ish project I'm working on where Python initially seemed like a good choice, but now we're regretting it for both performance and power usage reasons. If we'd gone with C or C++ initially we'd be having a much easier time optimizing. Not that I'm implying Python is bad, but if your target use case doesn't allow for a desktop or server, think carefully about what tech you use.
pjmlp 12y ago
Also achievable in JVM, .NET, ML family, Lisp family, Julia, D, Rust, Dylan with the added benefit of performance. I can't really envision using it for anything other than scripting.

sitkack 12y ago

If the application is properly decomposed into distinct subsystems one could take an entire subsystem and move it into C/Rust or Julia. Esp so if those subsystems are functionally pure.