[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: "Binary XML" proposals

  • From: "W. Hugh Chatfield I.S.P." <hchatfield@u...>
  • To: Sean McGrath <sean.mcgrath@p...>,"Henry S. Thompson" <ht@c...>, Tim Bray <tbray@t...>
  • Date: Tue, 10 Apr 2001 14:27:13 -0400

RE: "Binary XML" proposals
I don't remember whose rules these are - but I do remember these two
important rules on optimization (from quite some time ago back in my
programming days).

1) Don't
2) (For experts only) Only optimize those parts of the system you can
measure require optimization.

Cheers...Hugh

-----Original Message-----
From: Sean McGrath [mailto:sean.mcgrath@p...]
Sent: Tuesday, April 10, 2001 12:47 PM
To: Henry S. Thompson; Tim Bray
Cc: xml-dev@l...
Subject: Re: "Binary XML" proposals


At 17:24 10/04/2001 +0100, Henry S. Thompson wrote:
>Tim Bray <tbray@t...> writes:
>
><snip/>
>
> > Get some data on how much space and time a binary representation
> > will save, then you'll be able to make intelligent quantitative
> > decisions on where it's worthwhile deploying it.
> >
> > Until then, it's just amusing speculation.  -Tim
>
>I strongly endorse Tim's point.  I just wasted a weekend getting my
>schema validator to dump the internal form of the 'compiled'
>schema-for-schemas, on the _assumption_ that reloading that would be
>faster than parsing/compiling the schema-document-for-schemas every
>time I needed it.  Wrong.  Takes more than twice as long to reload the
>binary image than to parse/compile the XML.

I spent weeks sweating over a system that took over 3 minutes on average
to render a HTML page through a long series of server side processes that
involved lots of XML parsing of configuration files and such. The design
was clean, understandable but performance [expletive deleted].

The rush of code to the hand to speed up the parsing bit was hard
to resist. We calmed down. Took some deep breaths, ran the system
with profiling probes turned on. Dropped the data into Excel and
drew some graphs after a good nights sleep.

The performance problems had *nothing* to do with the XML parsing
and everything to do with unnecessary file IO. We dropped in a cache
- basically a 1 page change to a very large system and voila
latency dropped from 3 minutes to about 15 seconds!

You gotta run your figures on this sort of thing. If I had a days
holidays for every week I have wasted on an "obvious" performance
improvement over the last 18 years, I would not be seen on
XML-DEV till next April fools day.

regards,
Sean


------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@l...


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.