Hi Bruce,
Yes , the xsltransform streams the results to the writer as it transforms
and does not wait till the entire transform is finished to do it.
Regarding the cloning , since navigator is a pointer to node , the only way
to keep track of multiple nodes is to clone the navigator and make it point
to a different node. Since nodeset operations require the engine to keep
pointers to multiple nodes , the navigator gets cloned.
Cloning can be reduced by optimizing the stylesheet if possible. We have
done work to reduce the amount of cloning in whidbey , so that should help
as well.
Thanks
Nithya
"Bruce Dunwiddie" <Bruce Dunwiddie@discussions.microsoft.com> wrote in
message news:BD701200-5CB6-406C-9D2D-C5C1065B4B49@microsoft.com...
[quoted text, click to view] > I'm trying to build a couple classes that would allow for writing xsl
> transforms against data that is not originally xml. I've got an xmlreader
> implementation that seems to work well. Based on some issues with it and
> transforms, I then wrapped it up in a custom xpathnavigator
> implementation.
> Everything works fine from the transform functionality perspective, but
> it's
> not scaling well to larger amounts of data, and I would like to find out
> if
> these are framework limitations or results of my lack of knowledge.
> Specifically, if I pass my xpathnavigator object into the transform method
> of
> an xsltransform object along with a streamwriter instance, I'm expecting
> the
> transform to be able to stream the result to the streamwriter without
> needing
> to finish the entire transform first. Now, I could see some issues
> depending
> on xsl options, but in a perfect world, with a perfect xsl, is this at all
> possible? Also, I'm noticing that the xpathnavigator instance gets cloned
> like crazy, at least once per node, creating millions of instances during
> the
> transform. Can someone explain this to me?
