Lists Home |
Date Index |
At 2:11 PM -0400 4/15/04, Bob Wyman wrote:
>Manoj Sati says: "I once worked on a system software that processed a
>ton of XML ( all P2P exchanges were XML based ). The intention was the
>ability to look at the wire format cleanly. Needless to say, the
>performance left much to be desired. Changing XML to a proprietary
>binary format worked wonders."
>This is only one of many "testimonials" that could be collected that
>indicate that in at least "high-volume" XML applications, the
>conversion of XML to a compressed, fast binary format is a useful
>thing to do.
And they would likely all have the same value as Sati's does: bupkus.
Optimization and performance is not particularly difficult to
measure, but as here it's all too often not measured. Instead random
superstitions are pulled out of the witch doctor's bag, a little
magic binary dust is sprinkled around, and the problem goes away, or
at least everyone thinks it does. No one can really be sure because
nobody bothered to measure anything in the first place.
There are two big questions left unanswered by this bold assertion:
1. What if any techniques were used to attempt to optimize the XML
parsing? Which parser was used? Validating or non-validating mode?
Were external entities loaded or not?
2. Did the binary solution really do everything the XML solution did?
For instance, was it reliably checking the data? Over the years, I
would say most binary based systems I've seen make too many
assumptions about the correctness of the data they're reading and go
down in flames when a bit gets flipped in the wrong place. If the
binary solution was faster but at the cost of robustness, it's a
dangerous trade-off, especially for a P2P system where who knows what
buggy software is being run by different peers around the Net.
Elliotte Rusty Harold
Effective XML (Addison-Wesley, 2003)