Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: please coin a term for a lower order bug Date: Tue, 10 Jan 2012 22:11:44 -0800 Organization: albasani.net Lines: 63 Message-ID: References: <2pboqbqz49.fsf@shell.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net jJLGBbLfHeNa/EDqSBgWvBai4ua9i2qE/gY2mkW3EUwJ3ZqhcUEdCEXun2/gq5Paq5em2nuqibIEp33ZFPIf77mae6Qg0hEdv2P34ezCx0WsEX78rqedDulKBAirgF9v NNTP-Posting-Date: Wed, 11 Jan 2012 06:11:44 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="HOM06867lUJbgJEbo+tqeFbh29BlZbFRLUD9N/AUMbNlJII8PhbzgHHU0uL3KUcKiwJ8FNru9EcQXDfemskvQd4IHFDA26FAAZSKRi849LbTYlZpThNjvnKfnecoBQzX"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 In-Reply-To: Cancel-Lock: sha1:Cvgvbh8jTfKKgpqiXrD2URKM6QM= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11216 Gene Wirchenko wrote: > Lew wrote: >> markspace wrote: >>> Jim Janney wrote: >>>> Roedy Green writes: >>>>> What would you call a flaw in a program that had no effect on the >>>>> results, but needlessly made the program slower or confusing? >> >> Slower _is_ an effect on results. >> >>>> What about one that makes it more confusing and needlessly faster? >>> >>> "Needlessly faster" as in the customer didn't need a speed improvement in that >>> feature? I'd say that's Gold Plating. >>> >>> >> >> Only if it is superfluous code. Some very relevant and proper code makes >> things faster, such as use of a good algorithm. It isn't necessarily gold >> plating. > > If the speed was not required and the change was made to increase > the speed, then it is goldplating. That's a good way to tell the difference. We weren't talking about changes, we were talking about flaws, but regardless. No one posited that the change was not required, nor that it was made for the purpose of increasing speed. It is quite possible to make a change that is required or has a functional purpose that also, and inevitably, makes the program faster. Then it is not goldplating. Applying your litmus test can tell the difference. > I often write code that is not optimal for speed, because it is > easier to maintain. If the code had to be faster, I would modify it. > If it is fast enough, why bother? There are enough other things to > do. Quite so. But speed is not something to avoid, either, not if it is a byblow of better algorithm and smarter coding. It is as dangerous a religion to shun speed in the name of not prematurely optimizing as it is to chase it prematurely. There is also more than one metric of speed. When you do optimize for speed, make sure it's the right kind. I've seen performance choke on something sped up for the single-thread case when the target environment was heavily multithreaded. Lock contention cascades non-linearly after a threshold. Individual service response time is not the same as system throughput. Strangely (not), such premature optimizations were also horrid code with no functional purpose. To call them gold-plating does them too much credit. More like poop plating. A correct algorithm would have omitted the premature gold-, er, poop-plated monstrosity. And been both easier to maintain and faster. And used less memory. Gene, I agree with your points. But let us not swing too far the other way and eschew non-premature early optimization. Correct logic more frequently than not creates maintainable, fast and memory-efficient code as an emergent consequence. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg