Long term pointer access

[Jon Smirl <jo...@mediaone.net>]

Has anyone though about building a version of Xerces where pointers passed
through the event interface don't go bad? For example the chars pointer in
XMLDocumentHandler::docCharacters(const XMLCh* const chars,  const unsigned
int length, const bool cdataSection) is only valid as long as the call
lasts.

Small to medium size documents could be read from the input stream and
transcoded in entirety to a memory buffer. Long term pointers referencing
this buffer would then allow further processing on the document without
incurring a buffer copy.

The DOM could be very quickly constructed by bulk allocating the nodes and
then implementing copy on write.  An event based Xalan could also avoid
buffer copies until the final transcode for output.

Jon Smirl
jonsmirl@mediaone.net

Re: Long term pointer access

[Dean Roddey <dr...@charmedquark.com>]

White space normalization affects more than trailing and leading space. What
if there are character references in the text? And I'm sure if I tried I
could come up with 10 more issues.

Anyway, the point is that going down this road is a huge PITA. The Java team
went this way because of the poor performance of Java and they needed all
that they could get. But, the resulting architecture is far more complex
than that of the C++ parser. And they have to do the normalization and
whatnot once you actually access the data, i.e. you often still don't get to
just access it where it lies.

I don't think that there is any reason that your proposed changes should be
made to the Xerces parser. That would be radical enough a change that you
should write your own, or create your own completely different version of
the source base. I would be against any attempt to make this change to the
existing code base because of the complexity it would entail.

Even if it were conditionally done I'd be against, in fact that would be
even worse. Having that amount of conditional code is one of the worst
things in the world that can be done to a code base. If you want your code
to deteriorate to a point beyond maintainability, lots of conditional code
is the best way to do it. Much effort was put into the architecture to avoid
such things wrt platforms and compilers.

Far and away, the easiest way to do what you want to do is to provide an
'orphan' method on XMLBuffer. That way, if you, when you get the internal
callout, orphaned the buffer, the XMLBuffer object used internally would
just fault another one in upon the next use by the parser internally. Then
you could just steal the buffers and keep them around yourself, without
creating any significant extra complexity into the parser.

However, this would noticeable reduce the performance of the parser because
of the extra overhead of constantly checking whether a new buffer needs to
be faulted in. The XMLBuffer character append operation is probably the most
often called method of all. You'd have to fault another buffer back in
immediately upon orphaning.

Also, these buffers are used for a number of things internally. By the time
you get a call, any one buffer might be considerably bigger than the text in
it. So it could be quite wasteful in some cases.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


----- Original Message -----
From: "Jon Smirl" <jo...@mediaone.net>
To: <xe...@xml.apache.org>; "Dean Roddey" <dr...@charmedquark.com>
Sent: Thursday, August 10, 2000 10:46 PM
Subject: Re: Long term pointer access


> From: "Dean Roddey" <dr...@charmedquark.com>
> > It's not that easy. The buffer, as raw transcoded, is often not a valid
> XML
> > file. What if it references an entity? What about normalization of white
> > space?
>
> The entity would get loaded into it's own buffer. I'm looking for stable
> pointers, I don't care if Xerces uses ten buffers to achieve this. I just
> want to get rid of buffer copies.
>
> Normalization of white space would be achieved by making one
pointer/length
> pair for text in front of the white space and one for the text after.  The
> pointer/length pair for the white space in the middle could even point to
> somewhere else.
>
> Jon Smirl
> jonsmirl@mediaone.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>

Re: Long term pointer access

[Jon Smirl <jo...@mediaone.net>]

From: "Dean Roddey" <dr...@charmedquark.com>
> It's not that easy. The buffer, as raw transcoded, is often not a valid
XML
> file. What if it references an entity? What about normalization of white
> space?

The entity would get loaded into it's own buffer. I'm looking for stable
pointers, I don't care if Xerces uses ten buffers to achieve this. I just
want to get rid of buffer copies.

Normalization of white space would be achieved by making one pointer/length
pair for text in front of the white space and one for the text after.  The
pointer/length pair for the white space in the middle could even point to
somewhere else.

Jon Smirl
jonsmirl@mediaone.net

Re: Long term pointer access

[Dean Roddey <dr...@charmedquark.com>]

It's not that easy. The buffer, as raw transcoded, is often not a valid XML
file. What if it references an entity? What about normalization of white
space?

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


----- Original Message -----
From: "Jon Smirl" <jo...@mediaone.net>
To: "xerces" <xe...@xml.apache.org>
Sent: Thursday, August 10, 2000 10:10 PM
Subject: Long term pointer access


> Has anyone though about building a version of Xerces where pointers passed
> through the event interface don't go bad? For example the chars pointer in
> XMLDocumentHandler::docCharacters(const XMLCh* const chars,  const
unsigned
> int length, const bool cdataSection) is only valid as long as the call
> lasts.
>
> Small to medium size documents could be read from the input stream and
> transcoded in entirety to a memory buffer. Long term pointers referencing
> this buffer would then allow further processing on the document without
> incurring a buffer copy.
>
> The DOM could be very quickly constructed by bulk allocating the nodes and
> then implementing copy on write.  An event based Xalan could also avoid
> buffer copies until the final transcode for output.
>
> Jon Smirl
> jonsmirl@mediaone.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>