From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5ff6e0c3de8331c0 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 04 Jul 2007 06:15:03 -0500 Date: Wed, 04 Jul 2007 06:15:19 -0400 From: Jeffrey Creem User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: sub-optimal code for packed boolean arrays -- bug or inherent limitation References: <1183404856.375083.160890@q69g2000hsb.googlegroups.com> <1183485842.725620.199490@w5g2000hsg.googlegroups.com> <1183491750.177186.154490@k29g2000hsd.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <0j8sl4-pp5.ln1@newserver.thecreems.com> X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.147.74.171 X-Trace: sv3-uVc4Oi1QUGmq33LBgdOTfZQzFfuLBAju9EKB8WGoU61gn/4tdE2PORevaJp9ce9o/RWu3dSlfdy4fDB!d38ySV/4LuqAkiM9yEThU79G9GGCFrLz7zDwHMFX2Gg2Q+ycBjyoWO9OAIKWMGgYYrMvT2IUkAcj!PXoBGPq1MZdI25OkXZQ7DA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.35 Xref: g2news1.google.com comp.lang.ada:16409 Date: 2007-07-04T06:15:19-04:00 List-Id: Jeffrey R. Carter wrote: > My reaction is due to an allergy to premature optimization, the root of > all evil. > "Premature Optimization" is one of those pieces of conventional wisdom that gets repeated often but which is in fact not the problem at all..Not really. In any real-world problem, you rarely get to spend 6 months making it faster because you did such a poor job up front in designing the problem. Often, by the time one has created a design mess that is slow everywhere, spending the short time optimizing the scary loops is not enough because the design itself is broken. The real problem is not so much premature optimization but crazy micro-optimizations done early that also hurt maintainabilty/clarity of the code and often do little if anything to actually make the code faster. Spending time up front thinking about the overall design and even worrying a little about specific performance details when not taken to the extreme and when done with the benefit of metrics backed experience (v.s. I heard one time that compiler X was slow on this) is actually not all that bad. This is of course especially true when one considers that by the end of the project when you go to start profiling the code to find the hotspots and find out that your lousy tool set does not support profiling with programs with tasks, or does not support profiling of non-trivial programs at all.