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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Linear Search
Date: Thu, 29 Sep 2016 00:40:17 -0500
Organization: JSA Research & Innovation
Message-ID: <nsi9fb$q19$1@franka.jacob-sparre.dk>
References: <nsgrs8$a1j$1@dont-email.me> <e52ck2Fos4U1@mid.individual.net>
 <nsh8nk$4qh$1@franka.jacob-sparre.dk> <nshih3$lk$1@dont-email.me>
NNTP-Posting-Host: rrsoftware.com
X-Trace: franka.jacob-sparre.dk 1475127595 26665 24.196.82.226 (29 Sep 2016
 05:39:55 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Thu, 29 Sep 2016 05:39:55 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-RFC2646: Format=Flowed; Original
Xref: news.eternal-september.org comp.lang.ada:31939
Date: 2016-09-29T00:40:17-05:00
List-Id: <comp.lang.ada>

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:nshih3$lk$1@dont-email.me...
> On 09/28/2016 01:21 PM, Randy Brukardt wrote:
>>
>> Or, say compiling Ada and the search is in generated parse tables. (I was
>> able to speed up the parsing speed of our compiler by an order of 
>> magitude
>> by replacing the linear search for the next symbol by a tuned search.)
>
> Sure, I've done that, too. And when I did it, the time difference made the
> program significantly more responsive to users. But I was never searching
> anything close to 7M items. If I had written the same program today, with 
> the
> same linear search, it seems likely that it would have been fast enough, 
> and I'd
> never have needed to change it.

The problem with that logic is that people seem to expect to be able to 
compile ever-bigger programs with their much faster machines. I can't take 
all of that performance improvement for the compiler itself. (Indeed, we 
have a formal policy to take no more than the square root of the improvement 
for the optimizer, which is handled by limiting the maximum chunk that can 
be optimized.) And they also want the compiles to get done as fast as 
possible; million line programs aren't that uncommon. Sloppy algorithms can 
matter a lot. (Of course, the key is to only improve the ones that really 
matter, and not the other 90% that have no effect. But that 10% can be a big 
deal.)

                                     Randy.