On Thu, Nov 19, 2009 at 2:09 AM, Rob.Conde <rob.co...@ai-solutions.com>wrote:
> Hi David, > > I built the XalanTransformer sample and indeed the performance > seems fine there. Also I tried passing a stringstream instead of the > DOMStringPrintWriter and it seems to work fine…though I’m not sure if this > will handle encoding correctly. > As long as you treat the string as a sequence of binary bytes, you won't have any issues. The interesting thing about transforming to a XalanDOMString is that you override the output transcoding mechanism, since XalanDOMString can only contain UTF-16 code points. This can be problematic if your stylesheet doesn't specify UTF-16 as the output encoding. To parse the resulting document, you would need to explicitly force the encoding on the InputStream by calling InputStream::setEncoding() and passing in "UTF-16". > So I think you’re probably on the right track. Note that the code I posted > crashes at the end since terminate is called before the XSLTInputSource goes > out of scope – but this is unrelated to the original problem. > I will investigate the performance issues, but I suspect it has to do with re-sizing the XalanDOMString instance as it grows. You might try running your test application and adding a call to XalanDOMString::reserve() before you transform: domStr.reserve(35000000); This would reserve enough space in the instance so resizing would not occur. Dave
