<story><title>Rob Pike&apos;s Rules of Programming</title><url>http://users.ece.utexas.edu/~adnan/pike.html</url></story><parent_chain><item><author>zmmmmm</author><text>I feel torn about the &amp;quot;premature optimization&amp;quot; stuff. On the one hand it&amp;#x27;s clearly true that we&amp;#x27;re terrible at predicting bottlenecks and it makes no real sense to second guess them at any fine level of detail. On the other hand, I think about products that I love to use and they are all fast. I think about the first iPhone and how utterly crucial that first user experience was. Did they achieve that by just writing giant gobs of code and then circling back afterwards to fix a few hotspots? I think about how Chrome was such a delight after FireFox got slower and slower and more bogged down. Clearly, Chrome was written from the ground up to avoid that. I am not so sure you can really optimise for performance after the fact, at least not universally. There are times when you have to build it into the very fabric of a project right from the start. Once a project has a giant mass of moderately slow code, there&amp;#x27;s nothing you can do except rewrite it to get better performance.</text></item></parent_chain><comment><author>comlonq</author><text>Yes, that is exactly what Apple did with the iPhone. They wrote the interface then tested it over and over again and made optimisations on every iteration.. This was before it was released to the general public.&lt;p&gt;The article is talking about optimising before you can prove where the problems are... Apple had excellent testing which showed where a lot of issues were. Some issues may well have not been discovered until a wider audience had access though.&lt;p&gt;Testing can happen before you release a product you know? You new fangled startup MVP types only think good testing happens on paying customers. Fuck you guys.</text></comment>
<story><title>Rob Pike&apos;s Rules of Programming</title><url>http://users.ece.utexas.edu/~adnan/pike.html</url></story><parent_chain><item><author>zmmmmm</author><text>I feel torn about the &amp;quot;premature optimization&amp;quot; stuff. On the one hand it&amp;#x27;s clearly true that we&amp;#x27;re terrible at predicting bottlenecks and it makes no real sense to second guess them at any fine level of detail. On the other hand, I think about products that I love to use and they are all fast. I think about the first iPhone and how utterly crucial that first user experience was. Did they achieve that by just writing giant gobs of code and then circling back afterwards to fix a few hotspots? I think about how Chrome was such a delight after FireFox got slower and slower and more bogged down. Clearly, Chrome was written from the ground up to avoid that. I am not so sure you can really optimise for performance after the fact, at least not universally. There are times when you have to build it into the very fabric of a project right from the start. Once a project has a giant mass of moderately slow code, there&amp;#x27;s nothing you can do except rewrite it to get better performance.</text></item></parent_chain><comment><author>MrScruff</author><text>I think there&amp;#x27;s some truth to this. The assumption that there will be low hanging fruit in the profiler when you eventually start worrying about performance isn&amp;#x27;t always true.&lt;p&gt;Also, the more you worry about writing performant code, the easier it will be for you to write it that way in the first place without making sacrifices in code readability or maintainability. It&amp;#x27;s a myth that high performance code is always more complex and error prone. If performance is always something put off as something to address later, you can end up with as you describe &amp;#x27;a giant mass of moderately slow code&amp;#x27;.&lt;p&gt;What I do agree with is that picking the correct data structures has more of an impact that algorithm noodling, though that has it&amp;#x27;s place.</text></comment>