Discussion thread recap ('cause it spans about five pages):
Analog Kid said:
Look at how quickly amateur coders are putting out Cocoa apps. If you have more cycles to burn, you can focus less on optimizing and more on putting apps together quickly with more reusable code.
to which Rincewind42 replied:
Sure, it's great to be able to put an app together without writing more than a handful of code - but if you can do it so can thousands of others and your app really isn't all that distinctive in that sense then is it? A distinctive app requires a programmer to take full advantage of all of the tools available to him or her - including optimizing.
to which I replied (specifically at the first sentence above, not the second; I agree that optimizing is one of many tools, but not that a lack of optimization means an undistinctive app):
I disagree. A distinctive app requires more than programming prowess. It requires intelligent design, from the UI to the inner workings.
And now, back to the game ...
Originally posted by Rincewind42
And to optimize you must know that you are using the best algorithm. If you aren't already using the best algorithm, then you are wasting your time optimizing suboptimal code.
In my field, there is never "the best algorithm". There are a hundred different theoretical approaches (and more proposed monthly), and some of them may in some cases be far better than others (and in other cases far worse). Most of these approaches have never been tried in code yet.
So, I admit, this skews my thinking a bit. Optimizing a particular implementation of a particular algorithm is good, but more often than not getting the job done fast is more a matter of being flexible and allowing experimentation than honing an implementation to as sharp an edge as possible.
In other words, back to my original post: building an app out of mostly-reused code does not mean that "anyone" else could do it just as well. In some fields, yes it obviously does (but then again, "anyone" can optimize their code too). But in fields where fundamental innovation is still possible, where the race amongst competitors is one of approach and elegance of implementation, reusing code, even though it is not 100% optimal for your approach necessarily, is the difference between the leaders and the followers.
I mean, yes, I could be getting a good 20-30% gain by using C constructs (structs and arrays instead of classes and vectors) throughout. In fact, my project has a significant portion which remains straight C because we've never bothered to go in and change it. Is the remaining C code a performance advantage? No, far from it. It is the slowest section of our application, because it is poorly understood and thus never innovated. The rest of the application has a record of 100% performance gains year-over-year. That is not from low-level optimizations; that is from devising and implementing (quickly) new approaches to the problem at hand. While this section of code started off as the fastest bit in the project, the C code rarely gets faster, and so, year by year, becomes more and more the bottleneck of the system. I know the C vs C++ speed advantage because I'm finally rewriting this chunk and, yes, a direct rewrite with no approach change does slow that code down by a good 25%. Said rewrite, however, will allow this bit to improve in the same way the rest of the app has improved over the years (and in fact we have a few ideas to try here that look like they'll make the new code just as fast as the old code was ... ideas we'd never have dreamed of implementing on the old C code because it just plain would have taken too much time).
For the record, much of this same conversation took place on one of Apple development lists last week. That discusion concluded that optimization is a necessary step in development, not just so that things work well on older hardware, but also so that they work well on newer hardware.
Of course one has to make sure your code works on the lowest target machine. That doesn't mean you have to develop on a 400MHz G3 clunker, but it does mean you should sanity-check and monitor ongoing performance on such a machine. And, yes, optimizations have to take place (to a certain extent) to achieve this. As I said before, however, performance is not
only affected by assembly-level optimizations (by which I mean looking at the generated assembly and refining your C code to generate five instructions instead of eight). It is often (in my experience, at least)
more affected by higher-level optimizations.
AND such high-level optimization are more likely to work across multiple platforms than
any assembly-level optimization!
My application runs well on an old G3 (reasonably so; it scales pretty linearly with processor speed; it runs faster than the competition on all hardware) as well as half-decade-old P3s because we have used off-the-shelf modules and high-level ingenuity to quickly implement fast algorithms, not because we have unrolled loops and used pre-increments instead of post-increments and put loop variables on the stack instead of from the heap, etc.
I'm not against low-level optimizing. I just don't agree that it is the key differentiating factor between applications. It can differentiate, but the absolute lack of assembly-level optimizations does not mean your application is undifferentiated.
At some point, you have to review and clean up code, rethink your low-level approaches and, and run it through Sampler to get an idea of exactly where you are spending time. That doesn't mean you need to be writing your own implementation of vectors and hashtable maps. Using "stock" code does not mean you get poor performance.
