[Proj] Re: Premature optimization [was NAD problems on OSX 10.5 Leopard]

[strebe at aol.com]

Not to be a curmudgeon, Ed (and Norman), but that isn't what the quote means, and that is exactly what I meant by "Often misunderstood to mean, 'Engineering for scalability is the root of all evil.'" The original quote, in its full glory, is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." It is the "small efficiencies" disclaimer that is important.

Let us say your program is required (amongst many other operations) to sort a lot of numbers. You know from the beginning that "a lot" isn't just some fixed 12 values; it's arbitrarily large. But, in order to avoid "premature optimization", you throw in a simple bubble sort and proceed with the remainder of your programming.


Well. You haven't avoided premature optimization.  You've written the wrong program. It won't scale. Bubble sort's execution time increases exponentially as the number of items to sort increase. It's inappropriate for any but the tiniest counts of numbers. You should have used quicksort instead. C.A.R. Hoare knew this and had it in mind — he did, after all, invent quicksort.


Yet I constantly run into colleagues who excuse their program's performance failures running under stress as, "Oh, I wanted to get it working; now we can optimize it." Well. Optimizing means tuning your algorithm. It doesn't mean replacing your algorithm. If you replace it, you're writing a new program. You have completely lost the benefit of concentrating on the algorithm instead of the performance details.

The correct interpretation is, "Choose the correct algorithm; tune it later if you need to."



Regards,

-- daan Strebe





 





 



-----Original Message-----

From: Ed McNierney <ed at topozone.com>

To: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>

Sent: Fri, 18 Jan 2008 5:03 am

Subject: RE: [Proj] Re: NAD problems on OSX 10.5 Leopard






























Daan & Rich –





 





I think I’d want to remember that “premature optimization” really
reminds us to “make it work correctly, THEN make it work quickly”!  This is
related to the observation that any code can be made to execute arbitrarily
quickly as long as it is not required to produce the right answer.





 





I have to say that whatever its origin, I picked up the phrase
from my friend and co-worker Bob Frankston (author of VisiCalc), who was (and
is) fond of pithy pronouncements.





 





-         
Ed





 









From:
proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On
Behalf Of strebe at aol.com


Sent: Friday, January 18, 2008 12:21 AM


To: proj at lists.maptools.org


Subject: [Proj] Re: NAD problems on OSX 10.5 Leopard









 









 













"Premature
optimization" was probably coined by pioneering computer scientist C.A.R.
Hoare, who said, "Premature optimization is the root of all evil."
Sadly, this is often misunderstood to mean, "Engineering for scalability
is the root of all evil."





Regards,


-- daan Strebe













 









-----Original Message-----


From: Richard Greenwood <richard.greenwood at gmail.com>


To: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>


Sent: Thu, 17 Jan 2008 8:50 pm


Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard






On Jan 17, 2008 8:28 PM, Ed McNierney <ed at topozone.com> wrote:







> Rich -







>







> The one thing that significantly surprised me was how well that code







> performed on low-end machines.  I think I released it in 2002 - maybe







> 2001 - and there were plenty of "slow" computers visiting TopoZone.  I







> realize it's just math (other than updating the status bar with the







> formatted coordinate text), but I was really expecting to see some kind







> of lag if you waved the mouse quickly on a slow machine, but I never saw







> the slightest delay.  I have found that I sometimes worry excessively







> about performance!







>







>         - Ed















I believe it was you who coined the term "premature optimization",







which always gets a chuckle when I use it. And I too have been amazed







at the performance of the JavaScript code I ported that does one or







more a projections (or unprojections) and a 7 parameter datum







transform for every pixel the user passes over. I kind of remember







computer science texts that discouraged us from using floating point







math if it could possibly be done with integers.















-- 







Richard Greenwood







richard.greenwood at gmail.com







www.greenwoodmap.com







_______________________________________________







Proj mailing list







Proj at lists.maptools.org







http://lists.maptools.org/mailman/listinfo/proj






















More new features than ever. Check
out the new AOL Mail!













 






_______________________________________________

Proj mailing list

Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj




 


________________________________________________________________________
More new features than ever.  Check out the new AOL Mail ! - http://webmail.aol.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080118/502ac2fb/attachment.html>