[ontologiae]

Every programmers should know something about memory, because software are becoming bloat [1] [2] because of a new generation of programmers who doesn't optimize their code.

So, of course, you had a wonderful career, but it doesn't prove that you write efficient code

[1] http://www.rntz.net/post/against-software-development.html [2] http://tonsky.me/blog/disenchantment/

[esmi]

It really all comes down to what variable one is trying to optimize. I noticed neither article mentioned money as a possible variable to optimize. Here is another take to consider:

https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

"In 1993, given the cost of hard drives in those days, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, given the cost of hard drives in 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space. In real terms, it’s almost like Excel is actually getting smaller!"

[ken]

That's true, but I don't see how it's relevant to this article. We can simply tell people "Write your programs so they use fewer resources, and they will run faster".

Reading a paragraph like this:

> "The CAS signal can be sent after tRCD (RAS-to-CAS Delay) clock cycles. The column address is then transmitted by making it available on the address bus and lowering the CAS line."

is certainly interesting but it offers no additional insight in to how to write an efficient program. Regardless of whether the row and column addresses are sent on the same bus or a different bus, the optimization strategies for programmers are exactly the same. The same goes for almost all of the information here.

Unless you're writing a kernel, 99% of this article is overkill. I mean that literally: it's over 100 pages long, and I think the important and relevant points for most programmers could be summarized in a page or two.

[saberience]

Is it better for my company if the software is delayed to market by 6 months because we were writing the most optimal code possible in low-level languages gaining us 5% more speed on our application?

Most programmers are working for a business whose goal is to make money. Usually that involves adding more features or producing the product faster (as in development time). As far as optimal or efficient goes, all the company cares about is: "Is it fast enough so that people still buy/use the product?"

Premature optimization is wasteful, both a waste of time and money. Unless you're doing it for fun, trying to eke out 1ms on a website load at the cost of excessive dev time and risk of bugs, is just silly.

Don't forget, trying to make super optimal code often introduces bugs as you now have code that is more complex and/or uses more low level constructs. I've seen many deadlocks and race conditions due to engineers trying to optimize code unnecessarily.

[agentultra]

> Premature optimization is wasteful

More than premature pessimization? Setting your project performance goals is plain good design. It's not premature optimization to suggest that your web server should be able to respond to queries within an average window of time. Working with any kind of service level object and agreement practically requires you to think about these goals at the design phase regardless.

I've come across teams with engineers who couldn't understand why their application was timing out. They had no idea how to work with data structures and memory layout to optimize access. Their response to business stakeholders was to weakly raise their hands to the ceiling and say, "It can't be fixed." Their customers would not have been happy with that answer; they had precious data and reports to deliver.

It's worth knowing, at least on a conceptual level, how memory architectures and data structures affect performances. Otherwise you end up paying people like me a lot of money. And you don't want that.

[favorited]

> all the company cares about is: "Is it fast enough so that people still buy/use the product?

Studies have shown that is not the case.

Amazon found that every 100ms of latency cost them 1% in sales. Google found that 400 milliseconds means a nearly 0.5% decrease in search sessions.

So yes, a 5% speedup in an application could be an enormous win for a company.

[cortesoft]

I think the argument is that most programmers don't need to write efficient code.