[
Lists Home |
Date Index |
Thread Index
]
--- Andrzej Jan Taramina <andrzej@chaeron.com> wrote:
> "Premature optimization
> is the root of all evil"
> syndrome.
Right, premature optimization is indeed the root of
much evil. But after 6 or so years of experience with
XML, it doesn't seem appropriate to label concern
about XML's inefficiency "premature."
> First, they should architect and build their app
> using XML technologies which
> is a cost effective and less expensive way to get a
> project out the door fast
> (as others have pointed out). Then they should
> review their
> architecture/design/code and do some refactoring.
> Then, and only if you need
> to, look at what optimizations might be required.
> Many times that is "good
> enuf" and no more need be done.
One big reason for XML prototypes to fail to scale up
to production systems, AfAIK, is performance (or the
cost of buying enough hardware to overcome performance
problems). So, I think many organizations are at the
stage of buying into XML's (broadly defined to include
infoset-oriented technologies such as XPath, XSLT,
XQuery, SOAP) mindshare, network effect, ease of
implementation, etc. but are blocked by the
optimization issues.
>
> Availability of binary formats leads to temptation
> to prematurely optimize,
> which will get people into more hot water than
> taking a more standards-based,
> straightforward approach.
Good point! Still, you can't protect people from
their own folly. There will be some people in the
situation David Megginson described where reducing XML
parsing time to zero won't significantly affect
overall application performance, but they will use
performance optimized techniques anyway. One can only
hope that Father Darwin will weed out that meme in the
long run :-)
|
