premature optimization is the root of all evil

[Pat Farrell]

A lot of the postings in this section of Java Ranch strike me as worrying about performance far too early in the system's life cycle.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Also see
Wikipedia on Computer Science

[Ilja Preuss]

Absolutely true. And I don't say such things easily...

http://faq.javaranch.com/java/WhenToOptimize

[Nicholas Jordan]

Well the problem here is that the novice coder tackles a problem that they CAN understand. It is better,in general, for the struggler/juggler of all the re-invent-the-wheel to contemplate code path efficiency than to tackle improvements to com.eaio.stringsearch.BoyerMooreHorspoolRaita or design a DAWG [...edit: deletion so this sentence can be read...] before selecting an application subject for coding. This may be why problems ( selected areas of study ) are presented in the class-room setting.

It is my observation, backed by comments from other supervisors, that the insight ( abilitiy to concept reality ) evidenced by incoming class composition is declining at a chaotic drop, see: Seth Lloyd's hardcover words on this in "Programming the Universe: A Quantum Computer Scientist Takes On the Cosmos". In that work, the author makes metaphor using screwdriver. My observation is that today's harvest of souls is being reaped by a brain-stem nullifier in the form of a birrage of ahem, idiomatics, (that ninja warriors would probably study) resulting in the use of the word screwdriver eliciting video aftereffects of some belief system contradistincted to visualizing traffic on a pair of 16-U Rack Rails for 19" routers.
[ February 10, 2008: Message edited by: Nicholas Jordan ]

[Pat Farrell]

Originally posted by Nicholas Jordan:
Well the problem here is that the novice coder tackles a problem that they CAN understand.

My point is that they should focus on making the code work. Understand that. Then make it clean and extensible. Perfect the javadocs. Build JUnit test cases. etc. etc.

Optimization should be about 30th on the list of things to do.

[Nicholas Jordan]

Originally posted by Pat Farrell:


My point is that they should focus on making the code work. Understand that.

(....snip....()

I believe they are trying to do that, ( I understood the implied effort to make the code work ) and sought to build on your bravery. When the novice coder tackles a problem that they CAN understand, they are doing exactly that. Then on with javadocs, JUnit test cases, decisions of hashing v lists etc, all of which I have coming together right as a write this ( no phonics intended ) minute, and there is just an awful lot of real-world experience that allows me to juggle SecureRandom v Random v RandomIntGenerator by Horstmann in depth and reliability that cannot be challenged by today's wave when it comes to something like the YF-23 Black Widow II Advanced Fighter - which would have prevented something in Afghanistan that the India government may have laughed at. As well, a billion tons of mineral in Train Scheduling Problem is, in my opinion - which can stand moderate rebuttal - not effectively grasped by today's, ahem, 'crop' ~ which defines pretty much everything by concepting spoon-fed through a tube ( the tube ) and distinctly removed from Baryonic matter as far as their minds can be stretched.

I have to deal with them every day, I have sought to word this response to invite further work on the matter as it is well known in computer security that the greatest challenge is the human mind and the greatest risk comes from within. Because failure reduces Performance, premature failure is the root of all evil

These folks seem to think that's cool.

[Pat Farrell]

If you have rookies writing code for "YF-23 Black Widow II Advanced Fighter"
you have far more serious problems. 'tis a bit of a red herring.

For serious code, one tends to have two, five, or even ten times as much test code as code under test. Optimizations must be done after the code works.

[Jeanne Boyarsky]

Going back to the original statement, I think the word "premature" figures in greatly to the quote. If the design is not scalable enough, you may be doomed to a rewrite.

I agree that the low level optimizations we often get questions about in this forum are premature. However, all early optimization isn't premature. Then again, "optimization" probably isn't the best word for it.

[Pat Farrell]

Originally posted by Jeanne Boyarsky:
I agree that the low level optimizations we often get questions about in this forum are premature. However, all early optimization isn't premature. Then again, "optimization" probably isn't the best word for it.

Agreed that design for scaling is not optimization. Or even design for performance.

Its the frequent questions about trivial stuff, like whether an array is faster than an ArrayList, that are premature.

Knuth's books are all about optimization. Just not about worrying about it before you get the basics right.

[Nicholas Jordan]

Originally posted by Pat Farrell:
If you have rookies writing code for "YF-23 Black Widow II Advanced Fighter"
you have far more serious problems. 'tis a bit of a red herring.

For serious code, one tends to have two, five, or even ten times as much test code as code under test. Optimizations must be done after the code works.

Well, yes - that's about the size of it: Though I exaggerated greatly to draw out exactly that point. It's just something that is a 20,000 pound elephant on a $20 trycycle for me. I realized it would be taken as a red herring but clearly I made may point whether rational or not. My point would be that coders looking at ...whether an array is faster than an ArrayList,... instead of load time response of the disk heads or whether the data set is coming in on OC-1 are not going to be able to do effective testing unless the supervisors have a firm grasp on the hardware/software relationship.

As for the original centerpoint of the topic, jr stylizes strictly for the beginner so we would expect some form of this question style. My point is that as I code today, I am using work attained when I first sat down and wrote the first few lines of code. At that time, I determined a 64 byte datatype would be my fundamental unit, just a feel for how machinery operates. Given some leeway for bragging, that translates into 2048 bit which sorta fits in nicely with my work over the last few days enciphering a cleartext using JCE. Note I realize you will be leery of commenting on that because you are trained, my point - as I originally hoped to make - was that selection of a 2048 bit data block when I could not code int someint; is and was based on a feel for machinery generally.

It is the lack of this skill in the contemporary selection set that motivates me to draw the overblown parallel, but I note for the record that voice-recognition is being studied for the equipment because of some noteworthy human failures. 20,000 feet at 1,200 knots ( probably very cold and noisy ) in something that would make a doorway look roomy is removed from say perhaps a class 4 datacenter. If the beginner efforts appear misplaced, I respond that the true basis of that misplacement is isolation from reality - not lack of effort in the beginner's motivation.

A risky position perhaps, nothing ventured / nothing gained.
[ February 10, 2008: Message edited by: Nicholas Jordan ]

[steve souza]

Here is another good performance quote...

* "More computing sins are committed in the name of efficiency than for any other single reason-including blind stupidity" - W.A. Wulf