Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!mailrus!uflorida!novavax!proxftl!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.lang.c Subject: Re: Efficient coding considered harmful? Message-ID: <141@twwells.uucp> Date: 2 Nov 88 22:47:33 GMT References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <8630@smoke.ARPA> <1704@dataio.Data-IO.COM> <119@twwells.uucp> <273@tijc02.UUCP> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 109 In article <273@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt ) writes: : When I was optimizing I found some horrendous : "efficient coding" practices that were used that : made the code either less managable, less efficient : or both. : : Take, for example, my favorite: : : some_function(a_variable) : short a_variable; Here you are just demonstrating my point: had the programmer been trained to write efficient code, he'd have known that, in general, one doesn't declare short arguments (or float or char, for that matter). I'll repeat myself: I am not advocating optimizing one's programs, I am advocating learning the coding techniques which generally result in efficient code and applying them consistently. : The coder (who was inexperienced in C) wanted : to optimize the space needed to save the parameter : passed to the function. This actually may add to : the memory and time to do conversion between short : and int. Actually, declaring the thing short would not have been likely to save any stack space: the caller almost always has to push an int. (Except in ANSI C when there is a prototype, or in the unusual case that the compiler can do inter-function optimizations.) : The worst violation of coding for efficiency : was done in assembler. The person set a condition : bit inside a subroutine. After the return the bit : was used in a conditional jump. Of course, another : programmer saw the subroutine and couldn't under- : stand why there was an unneeded operation in the : subroutine and removed it. Sounds to me like a documentation error: that returned bit is part of the interface and should have been documented as such. Thus the error you use as an example of bad coding for efficiency's sake is nothing of the sort. : The time spent coding a project is only about : 10%. The maintenance phase lasts around 50% of a : project. If the coders write the most readable : code for the maintenance, the entire project cost : can be reduced. Here we get the same old argument, rehashed: "efficient code is unreadable". It is not necessarily true. And in many cases, the claim of unreadability is merely a demonstration that the reader does not make it a practice to read that kind of code, rather than a valid claim that the code is inherently unreadable. I'll go even further: while there is code that is both unreadable and efficient, the unreadability is more likely a consequence of the programmer's inability or unwillingness to express himself properly than a consequence of the code being written efficiently. I'll even go so far as to say that efficiency antagonists compound this. By setting up the false dichotomy of efficient vs. readable code, they convince programmers that they can either write efficient code or readable code, but not both. This merely makes people who believe in efficiency give up the attempt to make their efficient code readable. And, of course, their code is unreadable. My own code is both efficient and readable. The former I know because of testing; the latter because of feedback from people who have paid money for it. So, I know that one can have it both ways. : This is for a program to compute prime numbers: : : [code omitted, except for one line:] : for (i = 2; i <= root(n); i++) : : It is interesting to see that the square root : calculation takes this much time for a function : and is not needed to calculate primes. It was : probably an "optimization" to make the search : for primes quicker. It is more interesting to note that the simple discipline of avoiding computing a thing more than once would have been sufficient to get rid of most of the calls. Had the for loop been written imax = root(n); for (i = 2; i <= imax; i++) two benefits would have been had. First, no time would have been wasted waiting for or optimizing the thing. And second, the next person who read the code wouldn't have to figure out that root(n) is a loop invariant. (Trivial in this case, but not so in something more complicated.) : In conclusion, I would like to stress that : readability for the maintenance phase should : outweigh the importance of optimizing code as : it is written. Easy to read code is easier to : maintain, and easier to optimize. Well, you said it, but you utterly failed to demonstrate it. All that you have shown are examples of where bad programming leads to unreadable code as well as inefficient code. --- Bill {uunet|novavax}!proxftl!twwells!bill