Hacker News new | comments | show | ask | jobs | submit login

Define "run like shit". Would 1.5x - 3x the C++ speed be acceptable if your code was 70% more compact and proven secure, not to mention a joy to write?

No...? Is there another acceptable answer for this? In which cases is such an "upgrade" slowdown acceptable to the customer?

In the case that your app isn't CPU-bound, which is many cases.

[EDIT: Changed most to many. But I think arguments about whether or not speed matters are silly in the general case. Arguments about tradeoffs are always going to be so specific to your app that a general argument is fairly meaningless.]

Most cases for whom? There are plenty of fields in which being cpu-bound is the norm rather than the exception. There are a whole load of assumptions that go into any general advice like this, consider making fewer of them today!

That's like objecting to the statement "Most people have two arms, two legs and one head" by replying "For whom? There are plenty of demographics, such as amputees, where having a different number of arms or legs is the norm!" The fact that unusual things are normal for some subset defined by those characteristics is tautological. It doesn't make the general statement false.

> In which cases is such an "upgrade" slowdown acceptable to the customer?

In exactly those cases where the customer cares more about the added benefits (e.g. security, maybe more features) than speed.

For example, I use firefox even though I've noticed that Chrome is snappier because Firefox comes with addons that provide features that I cannot do without. In this case, I have made a tradeoff between speed and features.

Your customer doesn't give a crap if your program takes 0.03 seconds longer to execute, but he does care if you can't get the bug that keeps bringing his system down fixed in a timely fashion because your codebase is overwhelming.

CPU is vastly cheaper than programmer time. There is a point where the tradeoff becomes unprofitable, but to prioritize code speed over all else is a recipe for terrible software.

When we're specifically talking about how fast your typical GUI app can render toolbars and such, and the app in question sits idle waiting on user input 99% of the time, then that's a wonderful tradeoff.

If you're doing number crunching or heavy 3d, then it requires further thought, but if the code in question isn't one of your CPU usage hot points the conciser code is totally worth it.

There is no general useful answer to your question.

It depends on how the slowdowns translate to absolute slowdowns in human perceptible time. Which depends very much on the kind of problem, and whether a piece of code is on the "critical path" for anything.

1) When the customer can't tell the difference 2) When the customer benefits outweigh the perceptible slowdown 2a) When the faster code is broken (security or other bugs)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact