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

Re: Fast text output from SAX?

sax fast processor
it's precisely the end tag that is important. if you use a binary format
how do you know the end of the data is the end of the data? and how do
you know it is well formed? i don't think you can without a lot of other
overhead. checksums on tag content etc.

and it still has to be byte oriented to be portable. come to think of
it, it wasn't until agreement was reached on 8 bit bytes that a lot of
processor design could take off. another compromise.


On Sat, 2004-04-17 at 05:55, Dennis Sosnoski wrote:
> Elliotte Rusty Harold wrote:
> >Bob. You may not need to be lectured on this, but some other people 
> >do,as the plethora of software that crashes on unexpected input 
> >proves. It has been proposed in this very thread to use binary 
> >formats precisely to avoid the overhead of checking for data 
> >correctness. Just slam some bits into memory and assume everything is 
> >hunky dory. I have seen any number of binary formats that achieve 
> >speed gains precisely by doing this. And it is my contention that if 
> >this is disallowed (as I think it should be) much, perhaps all, of 
> >the speed advantages of these binary formats disappears.
> >  
> >
> Actually the speed advantages wouldn't be significantly changed, at 
> least not for XBIS. Since XBIS already uses handles to refer to names 
> it'd only need to verify the characters of a name the first time it sees 
> it; this would be very low overhead for most documents, where a limited 
> set of (element and attribute) names are used throughout the document 
> (which is the whole reason the handle approach is used in the first 
> place). XBIS already scans the characters of content, too, so it'd just 
> need to add a single conditional check in most cases to make sure a 
> character is legal. What else would need to be checked? Attribute 
> uniqueness could be handled by a fast hash index into an array of 
> booleans, with full comparions only needed on collisions. Those are the 
> main issues that come to mind for me.
> Most of the well-formedness issues of text XML (start/end tags missing 
> or out of order, attribute quoting errors, etc.) are impossible to 
> represent in XBIS format in the first place. I'd estimate that full 
> well-formedness checking wouldn't add more than 10% overhead to XBIS 
> performance. Of course, I fully expect you'll dispute this, Elliotte... :-)
>   - Dennis


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.
First Name
Last Name
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.