Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces design implementation?
 Tim Bray wrote: > At 05:06 AM 8/22/98 -0400, Tyler Baker wrote: > >I am sure this question has come up in private circles, but on this > >particular list the question of whether to integrate the current > >namespaces draft into the core of an XML parser/XML framework or else > >put it all in a layer on top of the parser/framework has not come up to > >date. > > I'm convinced that a high proportion of the XML docs flowing around > the web are going to have namespace apparatus in them, thus if I > were building a parsing system I'd build that right in at a low level. > > I'd be surprised if the extra cost of doing namespace processing were > significant or in fact noticeable. -Tim > Well for the parser I have (written in Java) is about 2x-3x as fast as XP right now when run in non-validating mode (it is a validating parser), so any additional processing, unless done elegantly could impact performance by as much as 10-20%. Right now without a JIT on a P-120 with 64 megs of RAM the Lark.xml file in your Lark parser (32K) gets parsed with my parser at around 280-300 milliseconds. XP does this in about 700-800 milliseconds, Aelfred in around 1200-1500 millseconds, and IBM's XML 4 Java in about 2800-3000 milliseconds. XML 4 Java is a validating parser so this might be some of the reason for the speed decrease as well as the overhead of building the in-memory parse tree that XML for Java uses. Nevertheless, building a DOM tree using my parser takes roughly the same amount of time (400 milliseconds with no JIT) as the timer test I have. The tests were done without a JIT because on the first pass, the speed of parsing a file is significantly increased because the JIT must compile all of the bytecodes into native form. For example, without a JIT XP runs at 700-800 milliseconds and with a JIT XP it runs at around 2100-2200 milliseconds. So the point is that whenever you add a new feature into XML you will either be slowing down the performance of parsers, increasing the memory overhead, or both. Or you may in effect force parsers to use inefficient implementations to support all of the features. I tried dabbling with streaming in XML data into the XSL processor I was working on and streaming it back out. The idea was to do this so you would not need to build an in memory parse tree like the DOM to parse the XML data into some sort of output using an XSL stylesheet. This would be possible if some of the built-in functions were removed as well as ECMAScript. Perhaps an XSL lite could be developed for systems where the output of a stylesheet and an XML document are simple, yet the performance needs let alone the memory needs are of great performance. I would like to keep namespaces as a totally separate part of the parser, but this would seem pointless if namespaces are expected to be a de-facto part of XML 1.0 anyways and may in the future be part of the official standard in XML 1.1. The main question I still have is: are namespaces ever likely to be a core part of XML, or will their utility be kept as a separate layer on top of XML? Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
