xml-dev - Re: Namespaces design implementation?

[Tyler Baker <tyler@infinet.com>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)