Mike,
You should be able to create a Java proxy class which holds the reference
to the transformed style sheet. The reference would be a private integer
variable within the proxy class. The Java code would never touch this
value -- it would be set and referenced soley by the C++ code.
Unless you are doing a "fork" and "exec" within your C++, then all of
the transformation should happen in the same process as the Java code.
As David notes, there is a fair amount of initialization overhead in
Xalan. I have not yet benchmarked the C++ code, but I found that the
Java version had an overhead of nearly 1/3 of a second (on a P3-800)
when processing an in-memory stylesheet that had already been compiled
using the processStylesheet() method.
Jeff;
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 08, 2001 6:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Using native call to Xalan-C++ from Java
On short transforms, the processor can spend 50% if its time initializing,
so you should use the XalanTransformer class if at all possible. You could
also use the C API, but there must be some way to proxy C++ objects in Java
through JNI.
Any time you can save a stylesheet or a parsed document, you're saving lots
of cycles, so you should try doing it. If you're doing multiple threads,
you can share the stylesheets and documents, but you can't share a
XalanTransformer instance.
Dave
Mike Garcia
<mike_garcia_m3@ To: [EMAIL PROTECTED]
yahoo.com> cc: (bcc: David N
Bertoni/CAM/Lotus)
Subject: Re: Using native
call to Xalan-C++ from Java
06/06/2001 06:05
PM
Please respond
to xalan-dev
Thanks for the response Dave.
All I'm doing is using the JNI (Java Native Interface) mechanism
in order to make this call.
I am spawing a new process between every native call, I think,
since I'm initializing every time. Do you think that that is
really a big performance hit and should be avoided?
We will be using the same stylesheet several times so I will
look into adding that capability. Do you suggest storing off
the compiled stylesheet as a static variable global to the file?
The way I understand JNI is that while the reference to the
object that loaded the Xalan shared lib is in memory, then that
library is held in memory. If this is true, then it makes sense
to hold the compiled stylesheet in a static variable. I still
need to do some testing on this.
your feedback is much appreciated.
Mike
--- [EMAIL PROTECTED] wrote:
>
> Hi Mike,
>
> Glad to hear that you're seeing better performance. I don't
> know how
> you're calling Xalan-C++, but if you're spawning a process to
> run the
> processor each time, you're probably wasting significant
> startup/shutdown
> cycles.
>
> There is a C API available. If you're able to map a const
> void* in C++ to
> some sort of Java value, you might want to try using it. The
> advantage is
> that you would only need to setup the processor once.
>
> There are also performance advantages if you're using the same
> documents
> and/or stylesheets multiple times. If you are, you can
> pre-parse documents
> or compile stylesheets and use the pre-parsed documents and
> compiled
> stylesheets multiple times. Theses objects are also
> thread-safe, so you
> can share them amongst multiple threads.
>
> Dave
>
>
>
>
>
> Mike Garcia
>
> <mike_garcia_m3@ To:
> [EMAIL PROTECTED]
>
> yahoo.com> cc:
> [EMAIL PROTECTED], pat Sherry <[EMAIL PROTECTED]>, (bcc:
>
> David N
> Bertoni/CAM/Lotus)
>
> 06/05/2001 05:35 Subject: Re:
> Using native call to Xalan-C++ from Java
> PM
>
> Please respond
>
> to xalan-dev
>
>
>
>
>
>
>
>
> Got it to work. We are now able to make native calls to
> Xalan-C++ from Java with an over 850% performance improvement
> with our xml/xslt files. The xml test file size I'm using is
> 18.6KB and the xslt file size is 12.2KB. We expect these to
> grow substantially in production.
>
> Our current usage is to give two strings to the java method,
> 1)
> pathToXml file, 2) pathToXsl file which returns the
> transformed
> string.
>
> I noted a 4.00 second transformation time with the Java
> implementation and a 0.47 second t-time with the C++ imp.
> These
> times are averages for 10 runs for each implementation.
>
> Environment: Win2000, P3-600MHz, JDK1.3, Xalan-C++ 1.1
>
> Many thanks to the Xalan-C++ developers. Your app rocks!! We
> will no doubt be using it in our production system once
> management sees these numbers.
>
> respectfully,
> mike g.
> IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
>
>
> --- Paul Winder <[EMAIL PROTECTED]> wrote:
> > We just tested 1.3.1 for Solaris in our environment and the
> > crash is gone.
> >
> > Evidently there is a bug in 1.3.02 on Solaris; perhaps on HP
> > too...?
> >
> > Paul
> >
> > At 07:36 AM 6/4/01 -0700, Mike Garcia wrote:
> > >Hey Paul,
> > >Glad to hear someone else is working on this too. We are
> > using
> > >Java1.3 on HP but I develop on NT. Right now we use Xalan
> > Java
> > >for our transformer but after messing around with Xalan C++
> > it
> > >would be great to be able to make a native call since the
> > >performance increase would be substantial.
> > >
> > >I can get the app to work solo but, when I try to pass in
> the
> > >data to my JNI implementation it crashes. I'm stuck at
> this
> > >point trying to figure it out.
> > >
> > >Mike
> > >
> > >This seems like some
> > >--- Paul Winder <[EMAIL PROTECTED]> wrote:
> > > > Hi Mike,
> > > >
> > > > Just out of curiosity, what JVM are you using?
> > > >
> > > > We're running XalanJ under JNI, and we've found that it
> > > > crashes with the
> > > > 1.3.02 Solaris JVM from Sun.
> > > > We had to revert to 1.2.2.
> > > >
> > > > I'd be interested to hear how your adaptation goes,
> since
> > one
> > > > of the
> > > > reasons we decided to use Xalan was the availability of
> > the
> > > > C++ implementation.
> > > >
> > > > Paul Winder
> > > > Arbortext
> > > >
> > > > At 10:17 AM 5/29/01 -0700, you wrote:
> > > > >Hello Xalan Developers,
> > > > >
> > > > >Please reply to my email address.
> > > > >
> > > > >We have been using Xalan Java for a while on our
> project
> > but
> > > > are
> > > > >noticing that its relatively slow when compared to
> Xalan
> > C++
> > > > (
> > > > >using the command line for both with samples of our
> > xml/xslt
> > > > >files). I'm noticing about .0005 seconds for the C++
> > > > >transformation and a 2.5 second transformation for
> java,
> > on
> > > > >average. I'd like to be able to make a native call to
> > Xalan
> > > > C++
> > > > >to perform the transformation since I think it would
> > greatly
> > > > >enhance our performance. What do you think?
> > > > >
> > > > >Currently I have a simple JNI implementation that takes
> > in
> > > > two
> > > > >string args. One for the xml source and the second for
> > the
> > > > path
> > > > >to an xslt file. Ideally I am attempting to convert
> > these to
> > > > >streams and use these streams to perform the
> > transformation.
> > > > >Using the SimpleTransform code, I compiled it into my
> > source
> > > > >however, when I try to run it from java, I get the
> > following
> > > > >error:
> > > > >
> > > > >#
> > > > ># An EXCEPTION_ACCESS_VIOLATION exception has been
> > detected
> > > > in
> > > > >native code outside the VM.
> > > > ># Program counter=0x8fd2b94
> > > > >#
> > > > >#
> > > > ># An EXCEPTION_ACCESS_VIOLATION exception has been
> > detected
> > > > in
> > > > >native code outside the VM.
> > > > ># Program counter=0x8fd2c63
> > > > >#
> > > > >#
> > > > ># An EXCEPTION_ACCESS_VIOLATION exception has been
> > detected
> > > > in
> > > > >native code outside the VM.
> > > > ># Program counter=0x245c8a53
> > > > >#
> > > > >
> > > > >interestigly enough, just before
> XSLTEngineImpl::process
> > > > method.
> > > > > I threw in lots of couts and the last one that prints
> > is
> > > > just
> > > > >before process then the above messages appear. The
> first
> > > > thing
> > > > >I was hoping to accomplish was to be able to run
> > > > SimpleTransform
> > > > >from a java call just to get it working.
> > > > >
> > > > >I have a suspicious feeling that this error might be a
> VM
> > > > bug.
> > > > >
> > > > >My questions are has anyone successfully done this? Is
> > it
> > > > >feasible for performance gains? Your advice is much
> > > > >appreciated.
> > > > >
> > > > >Respectfully,
> > > > >Mike G.
> > > > >BusinessEdge Solutions
> > > > >
> > > > >__________________________________________________
> > > > >Do You Yahoo!?
> > > > >Yahoo! Auctions - buy the things you want at great
> prices
> > > > >http://auctions.yahoo.com/
> > > >
> > > >
> > >
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Get personalized email addresses from Yahoo! Mail - only
> $35
> > >a year! http://personal.mail.yahoo.com/
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
>
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
