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!border1.nntp.dca.giganews.com!nntp.giganews.com!wns14feed!worldnet.att.net!attbi_s22.POSTED!53ab2750!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@acm.nospam.org>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
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>
   <PGwii.192991$_c5.68933@attbi_s22>
 <1183491750.177186.154490@k29g2000hsd.googlegroups.com>
 <huCii.12793$Fc.1922@attbi_s21> <0j8sl4-pp5.ln1@newserver.thecreems.com>
In-Reply-To: <0j8sl4-pp5.ln1@newserver.thecreems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <aFRii.194483$_c5.159927@attbi_s22>
NNTP-Posting-Host: 12.201.97.213
X-Complaints-To: abuse@mchsi.com
X-Trace: attbi_s22 1183573702 12.201.97.213 (Wed, 04 Jul 2007 18:28:22 GMT)
NNTP-Posting-Date: Wed, 04 Jul 2007 18:28:22 GMT
Organization: AT&T ASP.att.net
Date: Wed, 04 Jul 2007 18:28:22 GMT
Xref: g2news1.google.com comp.lang.ada:16411
Date: 2007-07-04T18:28:22+00:00
List-Id: <comp.lang.ada>

Jeffrey Creem wrote:
> 
> 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.

The rule is, "1st get it right, then make it fast." If you did a poor 
job up front, you didn't get it right 1st. And usually no amount of 
small, local optimization such as the OP is discussing will help you.

> 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.

That's pretty much the definition of premature optimization: extra 
(sometimes substantial) effort spent on obfuscation "for speed", done 
early, without any measurements to indicate that it will help.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08