>For my mind 'optimisation' is the process of breaking code maintainability for the sake of performance.
>Improving the performance, maintainability and efficiency of an application through fixing broken code and improving architecture is a very different beast.
Optimisation, in the broader term, is any change that improves performance, and we should probably throw in some bug fixes too. But more accurately, Optimisation is writing it right (including efficiency and speed) and maintainability, as pointed out elsewhere, comes down to documentation. If you don't have to rewrite something, it makes it much more maintainable, and that comes down to design.
The code using an XT to display results, surely must have been more complex than passing data to the XT to display, otherwise it would have been much more productive to rewrite the code in three days then to decipher the assembler code.
I think what people are not understanding, is that optimisation starts in the design and ends in the last bit, and is tight, with an best fit, to real world problem, design strategy. We have had enough of squint until it looks alright, strategies as solutions to real-time computing.
Posted Monday 25th June 2007 05:49 GMT
> If your application runs for long enough, or on enough machines, or on sufficiently high-end hardware, then it is still orders of magnitude cheaper to spend money on programmer time to optimize code than to just buy faster hardware.
> Too much current code runs too slowly.
> Too much current code is too buggy.
> Too many articles, like this one, take a simplistic view.
Whoever you are, you are right, the deficit to humanity, in time and money, to save an few greedy developers, and dumb lazy programmers, some time or money, has been staggering. The down time of one user can outweigh the cost savings of not getting an program right. I should know, I own an certain free, non-opensource, browser, that gets too much positive press around these circles.
By Francis Fish
>1. Run a profiler - it will tell you what's wrong. 99% of the time it isn't what you thought it was. 99% of the time it uncovers a bug! Nothing to do with optimisation.
>2. The examples given in the above comments, particularly the invariant in the loop one, assume that the compiler is too stupid to optimise things out. Usually the people who wrote the compiler are much cleverer than you are. Sorry, but it's true. Adding another variable may make the code difficult to understand, probably not in the contrived example though.
I wish it was so, compilers were using an smaller subset of functionality some time ago, and, in PC terms, Intel and MS improved on this, but I was reading an article last week showing how you still had to be careful of dumb compiler optimisations. Processor manufacturers even resorted to optimising for the subset of instructions used by the compilers. I have not written compiler optimisations, but from the complexity of optimising over the sheer number of instructions available, and human nature, I doubt many of these experts would do the job that thoroughly.