OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: COMPLEXITY BIG ISSUE (performance)


> 
> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC