Re: standalone vs. servlet

[Chuck Musser]

You both bring interesting points to light. I certainly get Anne's "machine efficiency vs. programmer efficiency" argument. I've managed to got lots done in Perl, Tcl and Javascript, so I'm biased against on-the-metal system programming languages. Java seems wonderfully expressive, but my concern was that its emphasis on being a nice language somehow resulted in unusably slow applications. I'm encouraged by Dennis's comment that slow Java applications are, more often than not, the programmer's own damn fault. I also understand that distributed systems have many potential bottlenecks. As an example, my proposed application uses Mozilla as the front end, so any perceived sluggishness may be the result of rendering lag, not SOAP message processing lag.

For the moment I'm going to fiddle with Axis and Jakarta-Tomcat (and let's not forget Apache) and see I come up with. Thanks for the insight.

Chuck

Anne Thomas Manes wrote:

I suspect that the use of reflection has a lot to do with the issue. Java
platforms use reflection to enable a bunch of dynamic features which are
really hard to reproduce in a C++ environment. You'll find this to be true
in SOAP platforms, servlet engines, and J2EE servers. It's a trade-off
between function and performance, and in most circumstances , function wins.

As for "my" platforms -- please recognize that I'm not with Systinet any
longer. I illustrated my point using WASP because Systinet is the only
vendor that provides Java and C++ implementations.

From what I've seen, the two top performing Java SOAP platforms are WASP and

GLUE. BEA and XMLbus are close behind. All of these systems offer
performance comparable to or better than .NET. I'd say that all of these
implementations have been very well designed and optimized. But none of them
can touch the performance of gSOAP, LEIF, or WASP for C++. I'm not sure how
to explain it other than to blame the platform. (Perhaps it's something
inherent to XML processing? There are some functions in which C++ really
excels over Java -- maybe XML processing is one of them.)

I don't want to sound as if I'm recommending C++ over Java. I'm just stating
a fact that among all current SOAP implementations, C++ implementations
offer better raw performance than Java implementations. I place a caveat on
that statement by stating that it's easier to achieve massive scalability
with Java by using a high-end Java application server. (You can certainly
achieve comparable scalability with C++, but you need to build the resouce
sharing and cluster facilities into your application -- which definitely
isn't easy.)

As far as I'm concerned, it's a pretty rare situation where performance
requirements outweigh those for productivity and maintenance. You can almost
always make up for performance by throwing more iron at the problem. You
can't make up for schedule delays caused by some nasty memory leak that no
one can find. From my perspective, Java is always my first choice for
language. Go with Java unless you have a compelling reason not to (e.g.,
your processing/memory capacity is fixed).

- Anne

-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 02, 2003 3:12 PM
To: [EMAIL PROTECTED]
Subject: Re: standalone vs. servlet


I think this is an artificial distinction, Anne. I'd suspect the
difference in performance of your SOAP platforms is due more to how
they're structured internally rather than to any inherent differences in
C++ vs Java. For instance, Java SOAP implementations commonly use
reflection to access data in objects, which is always slower than direct
access (even with the improvements that have been made in recent JVMs).
With C++ this is not an option. That said, there are also other issues
that may play into this particular application, such as the better
socket handling allowed by C++.

I don't know about the Tuxedo vs app server comparison, though my
understanding is that Tuxedo handles only one particular portion of the
work that's done by an app server and hence can be heavily optimized for
that one purpose. Servlet/JSP engines such as Resin have certainly shown
much superior performance vs IIS/ASP in the past, even though IIS/ASP
was an "integrated" component of the OS. I haven't seen the latest
figures now that MS as adopted a JSP-style compiled code approach for
ASPs, so it's possible the advantage has swung back the other way again.
The point is that implementation and internal design (not just tuning,
which is a last minute attempt to clean up some of the worst excesses of
poorly performing code) matter more than the choice of language.

- Dennis

Anne Thomas Manes wrote:

Dennis,

I absolutely agree with you regarding application code. Using

well-optimized

code and a good application server, you ought to be able to make a Java
application run at a speed that's reasonably comparable to a C++
application. There's a bigger difference, though, when it comes to
infrastructure code. In my experience, SOAP *platforms* built

with C++ run a

lot faster than those built with Java. Just as you won't find a J2EE app
server that can compare with Tuxedo.

Best regards,
Anne

-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 02, 2003 2:18 PM
To: [EMAIL PROTECTED]
Subject: Re: standalone vs. servlet


Anne Thomas Manes wrote:

There's no doubt that a C++ environment will offer higher

performance than a

Java environment. Ask Systinet. WASP for C++ is a *lot* faster

than WASP for

Java. The two environments use basically the same

architecture, but C is

just faster than Java. Even so I suspect that it would be

easier to make

WASP for Java support massive scalability than WASP for C++. All

you have to

do is deploy it in WebLogic. There isn't an app server comparable to
WebLogic for the C++ world. (well -- there's Tuxedo -- but I

don't know of

anyone who's developed a SOAP platform for Tuxedo yet). But

since C++ is so

much faster than Java, the threshold at which you need a really

high-end app

server is quite a bit higher.

There's no reason for massive speed differences between C++ and Java
aside from developers not knowing what they're doing. Well designed Java
code should be no more than a maximum of about 30-40% slower than
equally well designed C++ code (after loading and initial JVM
optimization). If you're getting worse results than that it's due to
your developers, not to the language/platform.

I've personally replaced C++ subsystems with Java subsystems that did
more work and did it several times faster, while being more maintainable
than the C++ code had been. I've also improved the performance of one
enterprise Java system by a factor of more than 100 in a few weeks work
(most of which was spent convincing the technical management of my
reasons, through a detailed timing analysis).

There does seem to be a tendency for Java developers to write horrible
inefficient code. This may be a side effect of Java features - with
garbage collection behind the scenes, and threads so easy to create,
it's very easy to ignore the performance implications of what you're
doing. Don't blame the platform, though.

- Dennis

Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Redmond, WA 425.885.7197