Hacker News Reader

Comment by crdoconnor | Hacker News Reader

>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.

View on HN

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".

>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

> 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.

Not only. Think of all these seconds of computing time, translated into watts, translated into coal or whatever pollution from electricity production, multiplied by the number of users your program has.

I think programmers should also consider the environment, even if it'd have more impact if everyone started by just not owning a car.

Unless we're talking about optimizing stuff that actually takes 100% of the CPU's or graphics card's power, it'd have more impact if just one person started not owning a car. Or even merely used it a bit less.

Appreciate the sentiment but it's not going to achieve anything. "Tut-tut" attitude is a lot less efficient than simply showing people why it's worth optimizing for their own sake. If it's worth optimizing at all, that is - GP's point is that it's not always worth it. Optimization has a cost. Development cost and maintenance cost. What's the point of making a program faster if nobody can ever really work on that piece of the code again?

By the way, the hour the programmer stays in the office overtime to optimize that code, using computers and lights and other machines, probably damages the environment more than your example before...

> By the way, the hour the programmer stays in the office overtime to optimize that code, using computers and lights and other machines, probably damages the environment more than your example before...

What if we're talking about the file-copy API in some widely distributed operating system? That's going to be multiplied by millions and millions of people, and therefore, being an obtuse devil's advocate, i argue that indeed it would have an appreciable impact on the environment.

If, however, you're talking about some relatively infrequently used GUI element in an application which has merely a million users, then okay, indeed, go home and don't waste another hour of lights and computers at your office :).

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.

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.

>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).

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.

... Which they did perfectly well in the 60s on a mainframe. Why does it take - conservatively estimating - a million times more CPU cycles now?

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/ [2] https://en.wikipedia.org/wiki/CICS - yes, "Initial release: 1968; 47 years 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...

I've worked on an old COBOL codebase and "reliable" is not a word I associate with it.

It is front page news when it goes wrong, tho', look at NatWest. So objectively speaking, it is pretty reliable.

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.

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.

>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.

Reply on news.ycombinator.com