Brian Frutchey wrote:
Thanks for the help. I have done the following as per your 3 suggestions, but
have noticed no increase in speed. Any other ideas, or can you point out
something I am doing wrong?
1) I already had my compiler set to build for release and optimize for speed.
good
2) I have now implemented a callback class, but still need the output as a
string to pass back to java, so I am still wrapping a stringstream in the
callback class - is this still bad for memory allocation? If so, what stream
do I use as I don't want IO to file (unless I have to), and I don't know how to
get a string from the other streams. I have changed my transform method to use
a compiled stylesheet and a XalanDefaultParsedSource. Here is the code for my
callback handler:
...
and some code from my transform method:
stringstream theOutXMLStream;
// CallbackHandler writes incrementally, saving on memory
allocation
StringCallbackHandler theHandler(&theOutXMLStream);
You're still using a std::stringstream as the target, which is going to
be very expensive. You will get much better performance if you use
std::vector and pre-allocate a reasonable amount of memory using
std::vector::reserve(). You can then use std::vector::append() to add
each chunk of the transformation to the vector.
Since you're also sending the result back to Java as a string, you might
want to experiment with forcing UTF-16 as the target encoding, so
there's no need to transcode the result to UTF-16. This has the
disadvantage that it take twice as much memory if your output is all
ASCII characters, so only do this if you can prove that transcoding is
expensive enough that it's worth consuming more memory.
// XalanParsedSource required to use callback on compiled
stylesheet
...
3) How does one test a DLL independently? Are you suggesting I compile as an
executable with a main method and test, and just assume the DLL will perform
similarly? My transform method prints out the system time very very often, so
I know the JNI interface isn't the slow part, just the
XalanTransformer::transform method call.
I simply meant you should test the performance of the transformation
without involving the JNI code. That will ensure that you are actually
testing the Xalan-C code without the influence of JNI. I suspect that
once you start passing back a large amount of data as a string, you will
see some performance issues.
Dave
