RE: [xml-dev] Will Father Moore save us from our sins? - was Re: [xml-dev] Eclipse: the new Emacs? (and the XML story)

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Sure.  

1.  Pick the value of value to you (speed or transparency).
2.  Optimize where return on that value is possible.

Optimizing a one off seldom returns much of value 
that is not intrinsic to its particular application. 
My experience is that we often don't know which 
cheap resources will, without much warning, become 
expensive (check the cost of mixed nuts at the grocery), 
or we hope against the facts (watch the guys with 
SUVs tanking up lately).

Discipline is worthy.  So is knowing when it doesn't 
apply.  Paraphrasing the IETF guys, make sure something 
is worth governing before designing or legislating 
a control.  That is the discipline of self-examination.

BTW: given your last paragraph, elements or attributes? ;-)

len


From: David Megginson [mailto:dmeggin@attglobal.net]

Bullard, Claude L (Len) wrote:

> Even when resources are cheap, discipline is worthy.  This is 
> when it is most worthy, not with regard to short term 
> economics, but long term health that is harder to come by as 
> any system ages and increases its interdependencies.  

I wouldn't go that far: when the optimization won't bring significant,
measurable benefits, I prefer clear code over optimized code: code that is
slightly slower or more memory-intensive but a lot more transparent and easy
to maintain will win over the long term.

The most important places to optimize are code inside a tight loop (say, the
main loop of an interactive game) and code used for common data types (say,
element, attribute and text nodes in a DOM).  Optimizing code that will be
called or instantiated thousands or millions of times is a good, easy hit;
optimizing code that will be called or instantiated once or a dozen times is
counterproductive.