RE: COMPLEXITY BIG ISSUE (performance)

[Michael Condry <Michael.Condry@eng.sun.com>]

I belive that some studies on "codesize" would be 
very interesting in understanding XML processing overhead.

1) Parser sizes
2) DTD/Schema sizes
3) XML message sizes
4) etc.

Any references?

Michael
> To: "'ebXML Transport'" <ebXML-Transport@lists.oasis-open.org>
> MIME-Version: 1.0
> Content-transfer-encoding: 7BIT
> Subject: RE: COMPLEXITY BIG ISSUE (performance)
> CC: "'ebXML Architecture'" <ebXML-Architecture@lists.oasis-open.org>
> 
> > 
> > One thing I haven't seen discussed is the actual XML processing overhead.
> > We have worked on parsing XML for two years and the experiences have
> > taught us that forming "efficient" XML is probably one of the most
> > important considerations for optimizing systems.
> > 
> > An XML message with <tag><tag><tag> "250kb garbage" </tag></tag></tag> 
> > will take heaps o' memory and time to load into the DOM and not give you
> > much of an advantage over text, yet many people write their XML this way. 
> > Also, the overuse of attributes can slow incoming parser and handling
> > routines.  A shallow, self describing XML message is ideal.
> > 
> 
> 	I think concern about performance impact is premature. 
> 
> 	Especially so with sizes you mention (ie x << 1Mb).  My 
> opinion is that performance is really an architectural problem within 
> the xml parser/translator, not with the message structure per-se.  
> Though I do agree there is a potential tie between some structural-
> styles and theoretic performance limits.
> 
> 	"end-tags" (which I see as the only important difference 
> between xml&edi) are a mixed blessing.  They make "moving-
> window" parsing/translation architectures difficult, but other 
> approaches that require memory resources (for the message, not 
> the schema) roughly on the order of message size remain viable.
> 
> 
> PDP