TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Tucker Taft <[log in to unmask]>
Date:
Mon, 12 Oct 1998 09:42:29 -0400
X-To:
Reply-To:
Tucker Taft <[log in to unmask]>
Parts/Attachments:
text/plain (32 lines)
> > > Even in C, with a good compiler, you're better off with machine
> > > optimization.  ......
> >
> > Kernighan and Plauger, way back in _1978_ wrote, "Don't sacrifice clarity
> > for small gains in 'efficiency.'....Let your compiler do the simple
> > optimizations."
> >
> Or, to put it another way (I don;t recall who said it originally),
> "It's easier to make a correct program fast than to make a fast
> program correct."

But neither is easy.  The best thing is to plan for performance and
correctness from the beginning.  If you don't think carefully
about the *big* issues relating to performance (I agree that
"micro" optimization is often misguided), especially
in the area of careful storage management, I defy anyone to truly
achieve competitive performance.

Interestingly, even when there is a garbage collector, storage
management planning is still critical (you might even say *more*
critical) if good performance is going to be achieved.

The notion that software engineering does not involve
engineering for performance is definitely specious in
my view.  In the same way we gag at the thought of "debugging"
an algorithm into existence, we should gag at the notion of
"debugging" a program into high performance.

> Mike Feldman

-Tuck

ATOM RSS1 RSS2