You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Jon Smirl <jo...@mediaone.net> on 2000/08/02 04:18:52 UTC
Is the Java version of Xalan/Xerces needed?
I've been lobbying some of the Xalan/Xerces developers to stop working on
the Java version and to concentrate on making a high performance C version.
I'm not advocating dropping Java support, Java would be supported via the
JNI interface. Existing Java programs would not even notice the changes if
they've been good about only using the public interfaces.
The main reason I'm asking for this is performance. Right now Xalan/Xerces
is too slow to be used in an interactive environment where every page the
browser sees is being generated via a XSLT transform. To service this market
Xalan/Xerces needs to be 10x faster than it currently is. A lot of thought
and effort is going to be required to achieve this kind of performance
boost.
Eliminating the duplicated effort would allow more programmers to
concentrate on a single code base instead of two. I also believe that is
possible to write significantly faster code in C than in Java.
What does everyone think, is a pure Java solution an absolute requirement?
Using JNI with a shared library is not a new concept to Java; part of Java's
core runtime libraries are already implemented this way. If pure Java is an
absolute requirement there are four other pure Java XML/XSLT engines
available.
My personal experience is with two libraries in my project that were giving
me performance problems under Java. I've converted both of these into C and
call them via JNI; I'm getting excellent performance results running this
way.
C++ plus JNI can be just as portable as Java. My libraries have almost no OS
dependence in them since they rely on getting things like I/O streams passed
into them from Java. All of the JVMs support JNI, even the Microsoft one. C
portability has been demonstrated by Apache and Mozilla's support on many
platforms. Even things like the DOM can be built in optimized C++ and then
use a JNI wrapper to provide a standard interface.
A simple way to experiment with this would be use Microsoft Visual J++ to
import MSXML3. This would be using COM plus autogenerated wrapper functions,
but it would give you a good idea of how it feels. JNI is even faster and
avoids the need for the wrapper functions. I've tried doing this and
performance is excellent.
Jon Smirl
jonsmirl@mediaone.net
Re: Is the Java version of Xalan/Xerces needed?
Posted by Dean Roddey <dr...@charmedquark.com>.
I agree that it would provide better performance (perhaps, probably, maybe
:-) But, you are going to open a bit can of worms if this is done. Not that
it can't be done, but supporting some of the stuff the Java version does
will be tricky with the C++ parser. Also, the speed gain of something like
JNI is going to be kind of proportional to the amount of times you have to
transition down through it. If you are doing it at a relatively rough
granularity (i.e. a good bit of C++ code executes for every call down
through), I'm sure you can make for some significant gains. But, and I'm
asking here since I don't know, I would think that having to wrap fine
grained stuff in JNI might offset the gains due to bazzillions of
transitions through the JNI interface, right?
Also, the Java parser team might well revolt if this were forced on them.
And, given the relalities involved, I'd kind of guess that it might come
down to forcing it if it were done. I.e. I don't think that they would
volunteer for it. But, I shouldn't speak for them I guess, since I don't
know that for a fact.
--------------------------
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>; "xalan" <xa...@xml.apache.org>;
"xerces" <xe...@xml.apache.org>
Sent: Tuesday, August 01, 2000 7:18 PM
Subject: Is the Java version of Xalan/Xerces needed?
> I've been lobbying some of the Xalan/Xerces developers to stop working on
> the Java version and to concentrate on making a high performance C
version.
> I'm not advocating dropping Java support, Java would be supported via the
> JNI interface. Existing Java programs would not even notice the changes if
> they've been good about only using the public interfaces.
>
> The main reason I'm asking for this is performance. Right now Xalan/Xerces
> is too slow to be used in an interactive environment where every page the
> browser sees is being generated via a XSLT transform. To service this
market
> Xalan/Xerces needs to be 10x faster than it currently is. A lot of thought
> and effort is going to be required to achieve this kind of performance
> boost.
Re: Is the Java version of Xalan/Xerces needed?
Posted by Paul Russell <pa...@luminas.co.uk>.
On Wed, Aug 02, 2000 at 06:36:02PM -0500, Eric Hodges wrote:
> We have to have a 100% Pure Java solution. We don't know where our users
> are going to run our product, so we wouldn't know what platforms to build a
> C implementation for.
Totally agree. As far as I'm concerned, a C/C++ implementation
is of little or no use to me or my organisation. We're using
Xalan with Cocoon in a J2EE environment which provides us with
what we believe is the quickest time to market without comprom-
ising software quality - something which we believe is fundamental.
Some of the other posters are right: Xalan needs speed improve-
ments, this we all know and acknowladge. The long term gap in
performance differences between C and Java are much less likely
to influence the performance of the engine than a change in
architecture, design or methodology.
Unfortunately, C++ and Java are fundamentally different lang-
uages and consiquently it's going to be difficult for the same
team to maintain both. I was a C++ programmer for many years
(I'm still 'better' at C++ than Java, even now) so perhaps if
there are enough people like me who can think in both languages,
the architecture will stay free enough of java and C++ depend-
ancies to be useful to everyone.
Is it time someone defined the interfaces in IDL so the java
and C++ halves of the project can work independently for the
most part?
As an aside, does Xalan2 have a separate CVS branch?
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: Is the Java version of Xalan/Xerces needed?
Posted by Scott Ellsworth <sc...@alodar.com>.
At 10:18 PM 8/1/2000 -0400, you wrote:
>I've been lobbying some of the Xalan/Xerces developers to stop working on
>the Java version and to concentrate on making a high performance C version.
>I'm not advocating dropping Java support, Java would be supported via the
>JNI interface. Existing Java programs would not even notice the changes if
>they've been good about only using the public interfaces.
I use Xalan and Xerces in some pure java programs. It is terribly
convenient to deploy by copying the four jars I need (xalan, xerces, jdom,
and my app). A bit of testing with my standard deployment directory, and
!poof!, it runs on another platform.
If the pure Java xerces is abandoned in favor c++, I lose that. To deploy
my app on OS X for the Mac, I need a compiled OS X library, while for vms,
I need a compiled vms library. Ick.
The existence of the high speed c++ implementation is good - it points out
yet again to Sun that more work is needed on optimizers and compilers, but
it should not be the only solution.
Scott
Scott Ellsworth
scott@alodar.com
RE: Is the Java version of Xalan/Xerces needed?
Posted by Paulo Gaspar <pa...@krankikom.de>.
I would not compare it with ASP/JSP either. But I prefer template
solutions like FreeMarker or WebMacro.
I have a project where I used XSLT and, for that very specific case
I thing it was the right solution. But in general it causes too
much trouble when the designers your work with are not very
technical.
Most popular "visual" Web Design tools (Dreamweaver, Frontpage and
so) are not prepared to deal with XSLT.
Besides, IMHO, tools like FreeMarker can provide what you need in a
template with a simpler syntax and are even more flexible/powerull
for some situations (e.g.: content management framework) at a lower
development effort cost.
In my current projects I still use data stored as XML and still
transform it with XSLT when needed.
I believe in XSLT usefulness. In some very specific situations I
even find it useful as template mechanism. However, I think that
this (template) use is hugely overhyped.
Have fun,
Paulo Gaspar
-----Original Message-----
From: cmccabe@choicehotels.com [mailto:cmccabe@choicehotels.com]On Behalf Of
Chris P. McCabe
Sent: Wednesday, August 02, 2000 06:03
And I would have to disagree about XSLT not being practical for web page
generation (Paulo's comment). It is a far better solution that ASP/JSP, and
has worked very well for us in practice. Our entire web site is dynamically
generated with Xalan/Xerces, and it is a much cleaner solution that anything
else I have seen with respect to maintainability. Retargeting it to
another platform (e.g. wireless devices) is delightfully simple.
Just thought I would share my experience.
Cheers,
Chris
Re: Is the Java version of Xalan/Xerces needed?
Posted by "Chris P. McCabe" <ch...@choicehotels.com>.
I am having good success using the Java versions of Xalan/Xerces, and if there
is still some performance that can be squeezed out of it, then I think it will
be very useful as a Java product. Having said that, I wouldn't be opposed to a
C version if it gave me much better performance, as long as it was ported to
all the platforms I will be using (currently Solaris and Linux). If it was
only a slight improvement, I would rather see the Java version stick around.
Performance is definately an issue with us, but I'm not convinced that we can't
get what we need from Java.
And I would have to disagree about XSLT not being practical for web page
generation (Paulo's comment). It is a far better solution that ASP/JSP, and
has worked very well for us in practice. Our entire web site is dynamically
generated with Xalan/Xerces, and it is a much cleaner solution that anything
else I have seen with respect to maintainability. Retargeting it to another
platform (e.g. wireless devices) is delightfully simple.
Just thought I would share my experience.
Cheers,
Chris
Paulo Gaspar wrote:
> 1 - There are other issues besides performance
> (Example: C versions are completely uninteresting to me.);
>
> 2 - Maybe xalan and xerces have a lot of room for improvement
> on performance;
>
> 3 - Was the impact of Hotspot on performance already evaluated?
>
> 4 - Generating web pages trough XSLT is one of the more hyped
> and less practical uses of XSLT I know of.
> There are much better template mechanisms - including for
> the Web Designers.
>
> (I still use XML data and XSLT for XML transformation... but
> not as a template mechanism.)
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Jon Smirl [mailto:jonsmirl@mediaone.net]
> > Sent: Wednesday, August 02, 2000 04:19
> > To: xerces-j-dev@xml.apache.org; xalan; xerces
> > Subject: Is the Java version of Xalan/Xerces needed?
> >
> >
> > I've been lobbying some of the Xalan/Xerces developers to stop working on
> > the Java version and to concentrate on making a high performance
> > C version.
> > I'm not advocating dropping Java support, Java would be supported via the
> > JNI interface. Existing Java programs would not even notice the changes if
> > they've been good about only using the public interfaces.
> >
> > The main reason I'm asking for this is performance. Right now Xalan/Xerces
> > is too slow to be used in an interactive environment where every page the
> > browser sees is being generated via a XSLT transform. To service
> > this market
> > Xalan/Xerces needs to be 10x faster than it currently is. A lot of thought
> > and effort is going to be required to achieve this kind of performance
> > boost.
> >
> > Eliminating the duplicated effort would allow more programmers to
> > concentrate on a single code base instead of two. I also believe that is
> > possible to write significantly faster code in C than in Java.
> >
> > What does everyone think, is a pure Java solution an absolute requirement?
> > Using JNI with a shared library is not a new concept to Java;
> > part of Java's
> > core runtime libraries are already implemented this way. If pure
> > Java is an
> > absolute requirement there are four other pure Java XML/XSLT engines
> > available.
> >
> > My personal experience is with two libraries in my project that
> > were giving
> > me performance problems under Java. I've converted both of these
> > into C and
> > call them via JNI; I'm getting excellent performance results running this
> > way.
> >
> > C++ plus JNI can be just as portable as Java. My libraries have
> > almost no OS
> > dependence in them since they rely on getting things like I/O
> > streams passed
> > into them from Java. All of the JVMs support JNI, even the
> > Microsoft one. C
> > portability has been demonstrated by Apache and Mozilla's support on many
> > platforms. Even things like the DOM can be built in optimized
> > C++ and then
> > use a JNI wrapper to provide a standard interface.
> >
> > A simple way to experiment with this would be use Microsoft Visual J++ to
> > import MSXML3. This would be using COM plus autogenerated wrapper
> > functions,
> > but it would give you a good idea of how it feels. JNI is even faster and
> > avoids the need for the wrapper functions. I've tried doing this and
> > performance is excellent.
> >
> > Jon Smirl
> > jonsmirl@mediaone.net
> >
--
Chris P. McCabe 602-953-4416 chris_mccabe@choicehotels.com
Senior Systems Architect - Information Technology Division
Choice Hotels International
RE: Is the Java version of Xalan/Xerces needed?
Posted by Paulo Gaspar <pa...@krankikom.de>.
As I detail in another posting, tools like FreeMarker or WebMacro.
(Using FreeMarker at the moment.)
My main reason is that it does not give so much trouble to designers
that use "visual" design tools.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Wednesday, August 02, 2000 06:15
>
> > 4 - Generating web pages trough XSLT is one of the more hyped
> > and less practical uses of XSLT I know of.
> > There are much better template mechanisms - including for
> > the Web Designers.
>
> what template mechanism do you find superior to XSLT for generating web
> pages?
>
> - donald
>
RE: Is the Java version of Xalan/Xerces needed?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 2 Aug 2000, Paulo Gaspar wrote:
> 1 - There are other issues besides performance
> (Example: C versions are completely uninteresting to me.);
>
> 2 - Maybe xalan and xerces have a lot of room for improvement
> on performance;
>
> 3 - Was the impact of Hotspot on performance already evaluated?
good points.
> 4 - Generating web pages trough XSLT is one of the more hyped
> and less practical uses of XSLT I know of.
> There are much better template mechanisms - including for
> the Web Designers.
what template mechanism do you find superior to XSLT for generating web
pages?
- donald
RE: Is the Java version of Xalan/Xerces needed?
Posted by Paulo Gaspar <pa...@krankikom.de>.
1 - There are other issues besides performance
(Example: C versions are completely uninteresting to me.);
2 - Maybe xalan and xerces have a lot of room for improvement
on performance;
3 - Was the impact of Hotspot on performance already evaluated?
4 - Generating web pages trough XSLT is one of the more hyped
and less practical uses of XSLT I know of.
There are much better template mechanisms - including for
the Web Designers.
(I still use XML data and XSLT for XML transformation... but
not as a template mechanism.)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Smirl [mailto:jonsmirl@mediaone.net]
> Sent: Wednesday, August 02, 2000 04:19
> To: xerces-j-dev@xml.apache.org; xalan; xerces
> Subject: Is the Java version of Xalan/Xerces needed?
>
>
> I've been lobbying some of the Xalan/Xerces developers to stop working on
> the Java version and to concentrate on making a high performance
> C version.
> I'm not advocating dropping Java support, Java would be supported via the
> JNI interface. Existing Java programs would not even notice the changes if
> they've been good about only using the public interfaces.
>
> The main reason I'm asking for this is performance. Right now Xalan/Xerces
> is too slow to be used in an interactive environment where every page the
> browser sees is being generated via a XSLT transform. To service
> this market
> Xalan/Xerces needs to be 10x faster than it currently is. A lot of thought
> and effort is going to be required to achieve this kind of performance
> boost.
>
> Eliminating the duplicated effort would allow more programmers to
> concentrate on a single code base instead of two. I also believe that is
> possible to write significantly faster code in C than in Java.
>
> What does everyone think, is a pure Java solution an absolute requirement?
> Using JNI with a shared library is not a new concept to Java;
> part of Java's
> core runtime libraries are already implemented this way. If pure
> Java is an
> absolute requirement there are four other pure Java XML/XSLT engines
> available.
>
> My personal experience is with two libraries in my project that
> were giving
> me performance problems under Java. I've converted both of these
> into C and
> call them via JNI; I'm getting excellent performance results running this
> way.
>
> C++ plus JNI can be just as portable as Java. My libraries have
> almost no OS
> dependence in them since they rely on getting things like I/O
> streams passed
> into them from Java. All of the JVMs support JNI, even the
> Microsoft one. C
> portability has been demonstrated by Apache and Mozilla's support on many
> platforms. Even things like the DOM can be built in optimized
> C++ and then
> use a JNI wrapper to provide a standard interface.
>
> A simple way to experiment with this would be use Microsoft Visual J++ to
> import MSXML3. This would be using COM plus autogenerated wrapper
> functions,
> but it would give you a good idea of how it feels. JNI is even faster and
> avoids the need for the wrapper functions. I've tried doing this and
> performance is excellent.
>
> Jon Smirl
> jonsmirl@mediaone.net
>
RE: Is the Java version of Xalan/Xerces needed?
Posted by Randy Waki <rw...@flipdog.com>.
Jon Smirl wrote:
>
> I've been lobbying some of the Xalan/Xerces developers to stop working on
> the Java version and to concentrate on making a high performance C version.
> I'm not advocating dropping Java support, Java would be supported via the
> JNI interface. Existing Java programs would not even notice the changes if
> they've been good about only using the public interfaces.
In our situation, a faster native XML parser wouldn't fit the bill.
DOM PERFORMANCE: A native XML parser might parse faster, but its DOM
implementation may very well be slower. Any tradeoff would be
application-specific, of course. Some applications (like ours) spend
much of their time manipulating the DOM tree after it is built,
traversing nodes and calling simple getter methods. A native DOM
implementation might actually decrease our overall performance since
every DOM method would have the marshalling overhead of a native call.
In a pure Java DOM, HotSpot can inline a number of the methods, making
the potential delta even greater.
BINARY COMPATIBILITY: Source code compatibility across multiple
platforms isn't always enough. There's binary compatibility, too. With
Java, we don't have to worry about building our application binaries for
every platform we target. One build works for all platforms. This is a
major simplification to the whole build/deploy process, a process that
needs all the simplification it can get. (Note that we're doing
server-side development and we must include the XML parser in our
distribution.)
-- Randy
RE: Is the Java version of Xalan/Xerces needed?
Posted by Eric Hodges <ha...@swbell.net>.
We have to have a 100% Pure Java solution. We don't know where our users
are going to run our product, so we wouldn't know what platforms to build a
C implementation for.
My suggestion is to attract more C developers and go off on your own and
make a kick ass C implementation. I don't think the 2 products should be
linked in any way, unless a link shows up through parallel development.
RE: Is the Java version of Xalan/Xerces needed?
Posted by Paulo Gaspar <pa...@krankikom.de>.
1 - There are other issues besides performance
(Example: C versions are completely uninteresting to me.);
2 - Maybe xalan and xerces have a lot of room for improvement
on performance;
3 - Was the impact of Hotspot on performance already evaluated?
4 - Generating web pages trough XSLT is one of the more hyped
and less practical uses of XSLT I know of.
There are much better template mechanisms - including for
the Web Designers.
(I still use XML data and XSLT for XML transformation... but
not as a template mechanism.)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Smirl [mailto:jonsmirl@mediaone.net]
> Sent: Wednesday, August 02, 2000 04:19
> To: xerces-j-dev@xml.apache.org; xalan; xerces
> Subject: Is the Java version of Xalan/Xerces needed?
>
>
> I've been lobbying some of the Xalan/Xerces developers to stop working on
> the Java version and to concentrate on making a high performance
> C version.
> I'm not advocating dropping Java support, Java would be supported via the
> JNI interface. Existing Java programs would not even notice the changes if
> they've been good about only using the public interfaces.
>
> The main reason I'm asking for this is performance. Right now Xalan/Xerces
> is too slow to be used in an interactive environment where every page the
> browser sees is being generated via a XSLT transform. To service
> this market
> Xalan/Xerces needs to be 10x faster than it currently is. A lot of thought
> and effort is going to be required to achieve this kind of performance
> boost.
>
> Eliminating the duplicated effort would allow more programmers to
> concentrate on a single code base instead of two. I also believe that is
> possible to write significantly faster code in C than in Java.
>
> What does everyone think, is a pure Java solution an absolute requirement?
> Using JNI with a shared library is not a new concept to Java;
> part of Java's
> core runtime libraries are already implemented this way. If pure
> Java is an
> absolute requirement there are four other pure Java XML/XSLT engines
> available.
>
> My personal experience is with two libraries in my project that
> were giving
> me performance problems under Java. I've converted both of these
> into C and
> call them via JNI; I'm getting excellent performance results running this
> way.
>
> C++ plus JNI can be just as portable as Java. My libraries have
> almost no OS
> dependence in them since they rely on getting things like I/O
> streams passed
> into them from Java. All of the JVMs support JNI, even the
> Microsoft one. C
> portability has been demonstrated by Apache and Mozilla's support on many
> platforms. Even things like the DOM can be built in optimized
> C++ and then
> use a JNI wrapper to provide a standard interface.
>
> A simple way to experiment with this would be use Microsoft Visual J++ to
> import MSXML3. This would be using COM plus autogenerated wrapper
> functions,
> but it would give you a good idea of how it feels. JNI is even faster and
> avoids the need for the wrapper functions. I've tried doing this and
> performance is excellent.
>
> Jon Smirl
> jonsmirl@mediaone.net
>