3 ms·

>Many of them will have some idea about theoretical time complexity, but then see nothing wrong with what should be a very trivial operation taking several seco

>Many of them will have some idea about theoretical time complexity, but then see nothing wrong with what should be a very trivial operation taking several seconds of CPU time on a modern computer. In my experience developers who over-optimize, or who optimize with disgusting hacks, are a vastly bigger problem than developers who don't optimize at all. There are a vast number of problems where a several second wait for the user is almost irrelevant compared to the damage done to the code base by optimizing those few seconds away.

gaius 11y ago
Not one-tenth of the problem as people who wrap trivial computations in "enterprise" crapware and use 100x the CPU they really need just to relay a few bytes of data from system A to system B. If you have ever used Java and XML I am looking at you. This has a real cost associated with it, servers, datacentre space, power and cooling, system administrators to look after it all, don't come for free. Not just money, the environment too.
- larsmak 11y ago
  Yes, but this "enterprise" crapware is the transaction system of your bank, and those "few bytes" are your last paycheck. Have some respect for the software that makes the world around you function.
  - gaius 11y ago
    ... Which they did perfectly well in the 60s on a mainframe. Why does it take - conservatively estimating - a million times more CPU cycles now?
    - praseodym 11y ago
      They're most likely still running all their transaction processing on a single mainframe (+another one for redundancy) with something like IBM CICS [1, 2]. And they most likely also have a lot more transactions than in the 60s (card payments, internet banking, etc.). [1] http://www.ibm.com/software/htp/cics/ http://www.ibm.com/software/htp/cics/ [2] https://en.wikipedia.org/wiki/CICS https://en.wikipedia.org/wiki/CICS - yes, "Initial release: 1968; 47 years ago"
  - coldtea 11y ago
    Most banks and payment systems have old, reliable codebases, a lot of them even in COBOL. Banks don't play with those systems often, and they don't use monstrocities like J2EE for them. It's the other kinds of enterprise systems that are crap and deserve no respect. Intranet apps in big corporations, the BS systems that always mess up your bills in services companies, slow as molasses web portals for big enterprises and organisations etc, ERP and CRM apps...
    - c22 11y ago
      I've worked on an old COBOL codebase and "reliable" is not a word I associate with it.
      - gaius 11y ago
        It is front page news when it goes wrong, tho', look at NatWest. So objectively speaking, it is pretty reliable.
- crdoconnor 11y ago
  >Not one-tenth of the problem as people who wrap trivial computations in "enterprise" crapware and use 100x the CPU they really need I still doubt that the CPU/power/cooling cost of having systems infested with hacky enterprise garbage is its biggest drawback. That crap also causes expensive bugs and huge maintenance costs (e.g. relatively simple programs that require a team of 12 programmers a month to implement the simplest feature).
- deleted 11y ago
  [deleted]
panic 11y ago
The grandparent post isn't talking about over-optimizing. You shouldn't have to add disgusting hacks to complete a trivial operation in less than a second.
- netcan 11y ago
  Yet both the efficiency the great-grandparent is talking about and the efficiency hacks that the grandparent is talking about exist. This is evidence of how hard it is to do everything right, especially if you have more than one axis along which you are trying to be right.
- crdoconnor 11y ago
  >The grandparent post isn't talking about over-optimizing. Nonetheless, warning bells go off inside my head whenever I hear that opinion expressed without the caveat "if it isn't a problem for the user, leave it the fuck alone". >You shouldn't have to add disgusting hacks to complete a trivial operation in less than a second. If a trivial operation takes more than a second that's almost always indicative of a bigger underlying problem of crappy code. Cleaning up dirty code that incidentally causes performance improvements is fine, but changing code specifically to make performance improvements without improving its overall quality leads to a downward spiral of shit.
lhecker 11y ago
So your opinion is "If it's slow it's okay, because it's safer than optimizing?". I'm sorry but I have to disagree completely... I'm currently rewriting the node-postgres module from scratch and my implementation is between 3 and >1000 times faster than the original (this is not even a joke). And you know why? Because the original actually contains those hacks you're talking about and not the other way around. And that's where your actual noticable inefficiencies far too often stem from: Inexperienced developers who don't know how to do it the easy way - inefficiencies due to huge workarounds that have hidden costs. E.g.: Not using builtin methods but writing buggy workarounds. Or even very basic stuff like: Using expensive functions within loops instead of hoisting those outside of it. I wouldn't even call those "optimizations".
- deleted 11y ago
  [deleted]
- CydeWeys 11y ago
  Nobody (hopefully!) is defending important library optimizations. The kind of unnecessary optimizations I think about as being undesirable are when you spend a week's worth of engineering effort and go through a potentially risky data migration just in order to improve the performance of a command-line production environment management tool that is run once per few months, that only takes a few minutes to run anyway, and whose data is cached server-side by the application running it anyway. Actual example from my software engineering career. But for library code, that potentially thousands or even millions of systems in production worldwide are going to be using? Hell yes. That is worth the time to improve. And kudos to you on improving Node postgres performance. That's awesome.
- crdoconnor 11y ago
  >So your opinion is "If it's slow it's okay, because it's safer than optimizing?". No. My opinion is that if it's slow you need to check to see if it's actually a problem for the users first before optimizing. Unless... >And that's where your actual noticable inefficiencies far too often stem from: Inexperienced developers who don't know how to do it the easy way I already said this below: >Cleaning up dirty code that incidentally causes performance improvements is fine

gaius 11y ago

Not one-tenth of the problem as people who wrap trivial computations in "enterprise" crapware and use 100x the CPU they really need just to relay a few bytes of data from system A to system B. If you have ever used Java and XML I am looking at you. This has a real cost associated with it, servers, datacentre space, power and cooling, system administrators to look after it all, don't come for free. Not just money, the environment too.

larsmak 11y ago
Yes, but this "enterprise" crapware is the transaction system of your bank, and those "few bytes" are your last paycheck. Have some respect for the software that makes the world around you function.
- gaius 11y ago
  ... Which they did perfectly well in the 60s on a mainframe. Why does it take - conservatively estimating - a million times more CPU cycles now?
  - praseodym 11y ago
    They're most likely still running all their transaction processing on a single mainframe (+another one for redundancy) with something like IBM CICS [1, 2]. And they most likely also have a lot more transactions than in the 60s (card payments, internet banking, etc.). [1] http://www.ibm.com/software/htp/cics/ http://www.ibm.com/software/htp/cics/ [2] https://en.wikipedia.org/wiki/CICS https://en.wikipedia.org/wiki/CICS - yes, "Initial release: 1968; 47 years ago"
- coldtea 11y ago
  Most banks and payment systems have old, reliable codebases, a lot of them even in COBOL. Banks don't play with those systems often, and they don't use monstrocities like J2EE for them. It's the other kinds of enterprise systems that are crap and deserve no respect. Intranet apps in big corporations, the BS systems that always mess up your bills in services companies, slow as molasses web portals for big enterprises and organisations etc, ERP and CRM apps...
  - c22 11y ago
    I've worked on an old COBOL codebase and "reliable" is not a word I associate with it.
    - gaius 11y ago
      It is front page news when it goes wrong, tho', look at NatWest. So objectively speaking, it is pretty reliable.
crdoconnor 11y ago
>Not one-tenth of the problem as people who wrap trivial computations in "enterprise" crapware and use 100x the CPU they really need I still doubt that the CPU/power/cooling cost of having systems infested with hacky enterprise garbage is its biggest drawback. That crap also causes expensive bugs and huge maintenance costs (e.g. relatively simple programs that require a team of 12 programmers a month to implement the simplest feature).
deleted 11y ago
[deleted]

panic 11y ago

The grandparent post isn't talking about over-optimizing. You shouldn't have to add disgusting hacks to complete a trivial operation in less than a second.

netcan 11y ago
Yet both the efficiency the great-grandparent is talking about and the efficiency hacks that the grandparent is talking about exist. This is evidence of how hard it is to do everything right, especially if you have more than one axis along which you are trying to be right.
crdoconnor 11y ago
>The grandparent post isn't talking about over-optimizing. Nonetheless, warning bells go off inside my head whenever I hear that opinion expressed without the caveat "if it isn't a problem for the user, leave it the fuck alone". >You shouldn't have to add disgusting hacks to complete a trivial operation in less than a second. If a trivial operation takes more than a second that's almost always indicative of a bigger underlying problem of crappy code. Cleaning up dirty code that incidentally causes performance improvements is fine, but changing code specifically to make performance improvements without improving its overall quality leads to a downward spiral of shit.

lhecker 11y ago

So your opinion is "If it's slow it's okay, because it's safer than optimizing?". I'm sorry but I have to disagree completely... I'm currently rewriting the node-postgres module from scratch and my implementation is between 3 and >1000 times faster than the original (this is not even a joke). And you know why? Because the original actually contains those hacks you're talking about and not the other way around. And that's where your actual noticable inefficiencies far too often stem from: Inexperienced developers who don't know how to do it the easy way - inefficiencies due to huge workarounds that have hidden costs. E.g.: Not using builtin methods but writing buggy workarounds. Or even very basic stuff like: Using expensive functions within loops instead of hoisting those outside of it. I wouldn't even call those "optimizations".

deleted 11y ago
[deleted]
CydeWeys 11y ago
Nobody (hopefully!) is defending important library optimizations. The kind of unnecessary optimizations I think about as being undesirable are when you spend a week's worth of engineering effort and go through a potentially risky data migration just in order to improve the performance of a command-line production environment management tool that is run once per few months, that only takes a few minutes to run anyway, and whose data is cached server-side by the application running it anyway. Actual example from my software engineering career. But for library code, that potentially thousands or even millions of systems in production worldwide are going to be using? Hell yes. That is worth the time to improve. And kudos to you on improving Node postgres performance. That's awesome.
crdoconnor 11y ago
>So your opinion is "If it's slow it's okay, because it's safer than optimizing?". No. My opinion is that if it's slow you need to check to see if it's actually a problem for the users first before optimizing. Unless... >And that's where your actual noticable inefficiencies far too often stem from: Inexperienced developers who don't know how to do it the easy way I already said this below: >Cleaning up dirty code that incidentally causes performance improvements is fine