Home

News: Try it yourself: XML processing faster in Java than .NET

  1. Sun has announced an XML Performance white paper which compares the XML Processing Performance between Java and .NET. Rather than publish numbers, Sun provided instructions and source code for end users to perform their own tests; TheServerSide has already heard about indepenent field tests showing Java running ~30% faster with the SAX test, and ~50% greater with DOM.

    Has anyone else run these tests and can show numbers?

    Sun Annoucement

    "Recently, a team of engineers from Sun compared the XML Processing Performance between Java and .NET. For example we found that the Java SAX parser significantly outperformed the .NET pull parser for the majority of use cases. We took care to ensure that the application code and hardware configuration used on both platforms were as similar as possible in order to make an objective performance comparison. We don't expect you to just to take our word for it; we've provided instructions and source code so that you can run the test yourself. Get the whitepaper to learn more about the XML tests that were used and download the source code from the Web Services Code Samples page so that you can evaluate the performance yourself!"

    Download the performance paper

    Threaded Messages (60)

  2. Report for C#
    ======================================
    ******* XMLMark Report Summary *******
          
    XMLMark Configuration:
    Agents = 4
    PullParserUsage = 100
    DOMUsage = 0
    Selection = 50
    Validation = 0
    ContentModification = 0
    StructureModification = 0
    Serialization = 0
    RampUp = 5
    SteadyState = 20
    RampDown = 5
    XMLDocCount = 1
    SchemaFile = ..\\..\\docs
    sm-inv.xsd
    OutputDir = ..\\..
    results
    OutputFilePrefix = XmlMarkSummary
          
    XMLMark Results:
    Throughput = 60.10000 Transactions/Seconds


    Report for Java
    ======================================
    ******** XMLMark Report Summary ********

    Agents = 4
    DOMUsage = 0.0
    SAXUsage = 100.0
    Selection = 50.0
    Validation = 0.0
    ContentModification = 0.0
    StructureModification = 0.0
    Serialization = 0.0
    RampUp = 5
    SteadyState = 20
    RampDown = 5
    XMLDocCount = 1
    schemaFile = ..\..\docs\sm-inv.xsd
    OutputFilePrefix = XmlMarkSummary
    OutputDir = ..\..\results
    OutputFileName = XmlMarkSummaryjava_20040213_125551

    Transactions per second = 21.15
  3. Java did 77 op/sec vs 60 op/sec of .NET (hotspot in action?). However .NET is paralle arbage collecting during while test (mem usage steady under 9M). Java VM on another hand is configured aggresively (-XX:+AggressiveHeap -Xms1024M -Xmx1024M) and runs at 413MB.

    Summary java run 28% faster and consumed 4500% more memory.
  4. Scratch that.[ Go to top ]

    Java did 77 op/sec vs 60 op/sec of .NET (hotspot in action?). However .NET is paralle arbage collecting during while test (mem usage steady under 9M). Java VM on another hand is configured aggresively (-XX:+AggressiveHeap -Xms1024M -Xmx1024M) and runs at 413MB.

    >
    > Summary java run 28% faster and consumed 4500% more memory.

    Dunno why sun decided to cheat like MS does? My VM refused to start 'cos it didn't have enough memory, so I downgraded the Xmx and Xms to 128MB. The peak memory usage in task manager showed 52MB after the first two bmarks after which my patience wore out. The results were 78,26 and 72,86 (probably few notches higher in reality since I was surfing the web while waiting the tests to finish)

    Maybe they (sun) wanted to get a little extra by configuring the memory usage so high that the testapp wouldn't need to GC at all? That could give ~5% increase on performance (at least they report that the concurrent collector lowers the performance by roughly that amount)

    In reality I'd expect the performance be quite similar, even the memory consumption since if you run .NET on windows the program can utilize the system libraries that are not calculated to application memory size.. Try running that with Mono and see how much memory it eats there..

    BTW: what kind of configuration did u have? I run the (first two) tests on 1,6 P4 Mobile.
  5. Tests[ Go to top ]

    I have dual P4@2.3ghz, hyperthreading on, 2GB ram. As far as JVM vs CLR goes, opening the jitted code dissassembly shows that they are very similar. Dedicated garbage collector tests show similar results too.

    All these tests put out on the internet cheat by allocating resources differently, by using different application architectures, or by picking on some poorly implemented API (like .net's regexp).

    As about pull vs push(sax) xml parsing, there is absolutely no reason why one would be slower than another. However it's clear that in real life scenarios push parsing forces developers to design state machines unique for each parsing need. The resulting code is bigger, more obfuscated and error prone compared to pull model.
  6. Not A Valid Test[ Go to top ]

    I challenge SUN to provide its test results on this thread. Just telling the developers that SUN's xml parsers are faster than MS parsers without evidence is bolony.
    I don't trust SUN when it comes to benchmarks. XML is backed into MS products and its an add on in JAVA products. Common sense would tell which one would be faster without even doing a bench mark test.

    Looking forward to SUN test results.

    Shepard.
  7. two Tortoises and one Hare (C++)[ Go to top ]

    Not taking Sun numbers at face value? ;) Anyhow, the real "hare" is MS XML 5.0 C++ parser which can be more than 20 times faster than both Java and C# in large xslt transformations. Just open a 2-3 MB xml file (with an xml-stylesheet directive) with the browser and watch the magic.

    Regards
    Rolf Tollerud
  8. Agree with you on that. The MSXML C++ implementation is way ahead in terms of raw performance - both during XML parsing and doing XSLT.

    Regards
    Vignesh.
  9. two Tortoises and one Hare (C++)[ Go to top ]

    Not taking Sun numbers at face value? ;) Anyhow, the real "hare" is MS XML 5.0 C++ parser which can be more than 20 times faster than both Java and C# in large xslt transformations. Just open a 2-3 MB xml file (with an xml-stylesheet directive) with the browser and watch the magic.

    There two points to make here, firstly if you have to use XML then use an XML binding technology rather than a traditional parser, JAXB, as an example, will run loops around both parsers.

    Secondly, if you have a "2-3 MB" XML file then you've surely chosen the technology to exchange data. The same data in something more logical would probably only be a few hundred K and would also have the added advantage of not needing parsing, a win-win situation.

    -John-
  10. so is it MS Vs. Sun ???[ Go to top ]

    If you are really talking about MS C++ implementation, then i am sure there some GCC implementation which will break that record too :)

    I think the XML parsing itself was a way to give a hint about how well your pefroamcne will be in real-life scenario.

    Also, now a days benchmarks are everything for enterprises.
  11. so is it MS Vs. Sun ???[ Go to top ]

    I'd agree but in view of what you said "now a days benchmarks are everything for enterprises" anyone with any sense would not have used XML internally in the first place.

    -John-
  12. ????[ Go to top ]

    XML support is part of J2SE from 1.4, so it i snot an addon.

    There are no reason to expect XML parsers to run faster
    when lodaed from rt.jar than from xercesImpl.jar, so ...
  13. I ran a test on my laptop..and in almost all cases Java [ 1.4.1_01 ] was faster than .NET by almost 20 - 30% approx.

    Eg. Net tps ==> 83.86000
        Java tps ==> 102.59333

        In almost all cases Java had more TPS than . NET.

       
    I am running on Win XP Pro, Pentium M 1.6 with 1 GB RAM.
  14. 20-30% is not impressive IMO. I think that there are not enough theoretical reasons why one bytecode would work much faster than another; therefore I consider CLR vs. Java comparison to be pointless. Of course on different stages of VM evolution one might work faster then another depending on quality of current VM implementation.

    In my experience C++ MS XML parser and XSLT processor does run MUCH faster than Java, and I suspect that CLR could take advantages of it much easier than Java.

    However, real world performance more depends on our code and design rather than on raw performance of individual parts. Here is an example, not so long time ago I have used a trick to make Java XSLT run 50 –100 times faster. You may read a about it at http://www.kgionline.com/articles/xsl_50_faster.jsp
  15. Actually I wouldn't be too surprised if the Java parser really was 20-30% faster than C# (provided it can use 10 times as much memory of course). After all, the .NET engineers did not have a great incentive- anybody will use the C++ parser for real work, which is very easy from C#.

    Regards
    Rolf Tollerud
  16. whatever[ Go to top ]

    Konstantin: 20-30% is not impressive IMO.

    Really? Those grapes were probably sour anyway.

    Konstantin: I think that there are not enough theoretical reasons why one bytecode would work much faster than another; therefore I consider CLR vs. Java comparison to be pointless.

    It's not at all about "byte codes." At that level, the CLR generally has local advantages (very well tuned code emitted from the JIT) while the Hotspot JVM generally has global advantages (more advanced / more tunable GC, much better inlining capability.)

    It's possible, though unlikely, that the 20-30% comes purely from the JVM vs. CLR speed. My guess is that some portion of it comes from the JVM, while the rest comes from some optimization that the Java XML libraries have added that the .NET XML libraries hasn't added yet.

    However, 20-30% is impressive if it's your app that is bottlenecked on processing XML, not so much because you'd switch from .NET to Java to get 20-30% better (probably a silly idea,) but IMHO because it means that Java is finally looking competitive in its standard Java XML libraries (instead of relying on something like TME's Glue product.) The XML benchmarking I did a while back showed the .NET libs outperforming the Java ones, so it's nice to see some real improvement on the Java side.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  17. here we go again[ Go to top ]

    Cameron,

    I though we been through this many times already!

    What happy you are to discover some small part that is a little faster in Java, totally disregarding that MS has a C++ product that is 20 times faster.

    It is the memory management that is fucked in Java and the reason for the slow performance in everything in the way of finished applications, Web or desktop.
    Performance should always be measured with the same amount of memory.

    Regards
    Rolf Tollerud
  18. here we go again[ Go to top ]

    It is the memory management that is fucked in Java and...


    Rolf, I know English isn't your first language but there's no need to stoop to Eddie Murphy style adjectives.

    -John-
  19. here we go again[ Go to top ]

    Performance should always be measured with the same amount of memory.


    On of those statements that sound so true when you read them the first time, but echoes so falsely when you contemplate on them for a while. "Performance should always be measured under the condition that all tested code runs under the acceptable memory constraints", would be a better proverb.
  20. here we go again[ Go to top ]

    Rolf the Microsoft Drone: Performance should always be measured with the same amount of memory.

    Johan: On of those statements that sound so true when you read them the first time, but echoes so falsely when you contemplate on them for a while.

    WTF?! You seem to be arguing against the need for a level playing field. Perhaps that best test would be to run both rivals on the same machine at the same time. The rival that outperforms in such stress would be the winner to me. Objectivity. You should try it some time.
  21. here we go again[ Go to top ]

    Rolf the Microsoft Drone: Performance should always be measured with the same amount of memory.

    >
    > Johan: On of those statements that sound so true when you read them the first time, but echoes so falsely when you contemplate on them for a while.
    >
    > WTF?! You seem to be arguing against the need for a level playing field. Perhaps that best test would be to run both rivals on the same machine at the same time. The rival that outperforms in such stress would be the winner to me. Objectivity. You should try it some time.

    I´ll just repost the original reply, read it again and try to understand it this time:

    "On of those statements that sound so true when you read them the first time, but echoes so falsely when you contemplate on them for a while. "Performance should always be measured under the condition that all tested code runs under the acceptable memory constraints", would be a better proverb."
  22. here we go again[ Go to top ]

    Rolf the Microsoft Drone: Performance should always be measured with the same amount of memory.

    >
    > Johan: On of those statements that sound so true when you read them the first time, but echoes so falsely when you contemplate on them for a while.
    >
    > WTF?! You seem to be arguing against the need for a level playing field. Perhaps that best test would be to run both rivals on the same machine at the same time. The rival that outperforms in such stress would be the winner to me. Objectivity. You should try it some time.

    What if someone said that the level playing field should be on an iSeries, or maybe a Solaris installation? Or the latest MS server? There aren't any level playing fields in these performance comparisons, just the different sides manipulating them to suit their own products best.
  23. What if someone said that the level playing field should be on an iSeries, or maybe a Solaris installation? Or the latest MS server?

    If Java wants portability, it should expect trialing on those platforms. I realize .NET is a no-show on many platform kinds. Ideally a contest occurs on cheap hardware, which is the market's mode.
  24. These performance tests are not so important when compared to this:

    http://samgentile.com/blog/archive/2004/02/12/11304.aspx

    Even if .Net would end up a great technology, it is risking being misused by the thousands of ASP and VB programmers who don't have a clue about distributed systems, transactions, ACIDity, etc. They have a long way to go until they can have the same notion of the complexities involved in large scale enterprise applications that Java developers have had for years. And when .Net developers get there, Java will already be on the "next big thing", being it AOP, SOA, lightweight frameworks, or whatever, as it is already starting now. Java community just has to keep on innovating, and not worring about meaningless performance tests.

    Regards,
    Henrique Steckelberg
  25. Distributed transactions and 2PC is a no-brainer in Intranet environment, which MS has done for years with DTC and COM+ . Just because the Sun decided to make a mess of it with two competing technologies EJB and CORBA, both made by a committee, ridiculously overcomplex, more or less overlapping, and in addition encouraged to use them even in simple Web applications, don't blame MS!

    In modern scenarios we need to master the much more challenging task about how to get ACID to work with Web Services and SOA and the Java developers seems both unwilling, or to have a hard time understand, the new loosely coupled world. In almost every post I see: "WS is overrated, WS is over hyped, Java Technology X is better that WS etc. The attitude doesn’t help.

    Coordinating Web Services Activities with WS-AtomicTransaction and WS-BusinessActivity
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsacoord.asp

    Secure, Reliable, Transacted Web Services: Architecture and Composition
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsOverView.asp

    Regards
    Rolf Tollerud
  26. I am not blaming MS, they have their own huge community of ex-VB programmers to be worried about. Java doesn't have this legacy in its way to evolution, as .Net is having rigth now, as the blog mentioned. What is the use of WS when your developers think that acid is the property of lemons and not of transactions? MS will have a huge job of creating a new mentality on what is a great percentage of .Net developers which evolved from VB and ASP. You don't learn OO, patterns, the correct usage of O/R mapping, clustering, caching, etc., from night to day. These are not simple solutions applied to simple systems as you may think, these are complex problems which require greater expertise than drag-and-dropping controls on a UI, and which most enterprise Java developers have dealed with long before .Net was conceived.

    Regards,
    Henrique Steckelberg
  27. If will not take up to much space here because I am afraid this discussion is of topic, but,

    1) OO
    2) O/R mapping
    3) Clustering
    4) Caching

    All this topics is treated wrongly in Javaland- you should look to Microsoft to get enlightment.
    Looking forward to stimulating discussions.

    Regards
    Rolf Tollerud
  28. Please throw away your concepts[ Go to top ]

    Rolf,

    There you go again with the "Fire Engine is Red" stuff. Not sure what any of this has to do with the price of beans. You gotta back some of this stuff up dude.

    However,

    >>1) OO
    -How does MS outstrip java here? C# is mostly the same in terms of OO constructs as Java.
    >>2) O/R Mapping
    The Java/J2EE community is way ahead of MS. This is likely just because they've had more time to evolve but Cocobase, Toplink, OJB, Hibernate and yes EJB's are far more fully featured, tested, used than most of the .NET equivalents (http://www.novicksoftware.com/TipsAndTricks/Tips-Object-Relational-Mapping-for-.net.htm)

    side note: Pretty cool that there are some Open Source .NET ORM tools.

    >>3) Clustering
    Your kidding right? .NET isn't even close to the likes of Websphere, Weblogic, or even JRun/JBoss here at the middleware level. And at the operating system level they're even less close.

    4) Again I just don't see it. All of the J2EE vendors have pretty good caching, OSCache works pretty damn well (and in clustered environments see #3), and I have yet to see anything in Java, C++, or the MS world that comes even close to Tangosol (again, also in clustered environments).

    Now, most of these things are inded moving forward for MS and .NET. And I fully expect them to be good. I'm not making statements about the quality of .NET or .NET developers. It's simply a matter that the J2EE and Java stuff has been in the works a lot longer. The .NET ones may end up even better as they build off the mistakes made in other communities.

    Jason McKerr
    The Open Source Lab
    "Open Minds. Open Doors. Open Source."
  29. Please throw away your concepts[ Go to top ]

    Well I go on then, but I expect every minute to get stricken by lightening from Java-Gods, or bashed by the "off topic" jury.
    Remember in this discussion that we are talking "Enterprise development", not constructing operating systems or language frameworks like Java or .NET. These guys have hundreds of more time and money.
    _______________________________________________

    For the first (ok, laugh if you want), I am not really against Java or Linux, only good natured banter "My dad is stronger than your dad" type of stuff, not really serious. The Spring Framework for instance, is the -best- piece of code I ever seen, no joking.

    But what I am deadly serious about and against is the attitude and the practices in the J2EE camp.

    Jason: OO -How does MS outstrip java here? C# is mostly the same in terms of OO constructs as Java

    1) It is my firm opinion that large systems can only be constructed from totally autonomous modules that does not inherit or depend or any common libraries- that totally distrust each other.Inside each module you can use OO to your hearts content. What the J2EE camp do wrong IMO, is to try glue too large inter-dependent systems together.

    Jason: O/R Mapping
    The Java/J2EE community is way ahead of MS. This is likely just because they've had more time to evolve but Cocobase, Toplink, OJB, Hibernate..


    Objectspaces is probably going to blast these tools but it is not that that matter I am against O/R mapping all together. By all means, use them if your time-money schedule is really tight, but do not expect the same quality as carefully handcrafted code using Stored Procedures or Spring or iBates or something similar..

    Jason: Clustering
    Your kidding right? .NET isn't even close to the likes of Websphere, Weblogic, or even JRun/JBoss..


    If you know from the beginning that your application is going to be clustered you should make it 100% stateless, which means that you must handle your sessions yourself, not use any container dependent sessions, no container variables at all, and of course only relative paths. If you keep to these simple rules clustering is a piece of cake.

    Jason: Again I just don't see it. All of the J2EE vendors have pretty good caching, OSCache works pretty damn well..

    Caching should be judiously thought out and planned already during the coding process and integrated with the -performance,performance,performance- thoughts. It is nothing that can be slapped on as an afterthought to help save a hopeless mess- where it might work or might not work like a lottery. Of course if you already have finished your app it is your only hope..

    Regards
    Rolf Tollerud
  30. Don't get fluster clucked[ Go to top ]

    Rolf: If you know from the beginning that your application is going to be clustered you should make it 100% stateless, which means that you must handle your sessions yourself, not use any container dependent sessions, no container variables at all, and of course only relative paths. If you keep to these simple rules clustering is a piece of cake.

    If you stick to those rules, it's probably not clustering ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  31. Please throw away your concepts[ Go to top ]

    /begin
    It is my firm opinion that large systems can only be constructed from totally autonomous modules that does not inherit or depend or any common libraries- that totally distrust each other.Inside each module you can use OO to your hearts content. What the J2EE camp do wrong IMO, is to try glue too large inter-dependent systems together.
    /end

    Now read that again and think of Microsoft.

    "totally distrust each other" - Microsoft modules trust each other rather too much - viruses

    "too large inter-dependent systems" - Again Microsoft. This was a major part of the arguments in the lawsuit.

    "does not inherit or depend or any common libraries" - think DLL hell.

    Fix your camp first. Then think about fixing Java.
  32. Well, I was expecting that you would give us something that MS has about those 4 subjects that could enligthen us, but instead you gave us you personal opinion of what enterprise development should be (and that would of course not fit every problem). I take it that it is not MS's stance on the subject, or else some megalomania has developed somewhere...

    Either way, your post just proves even more what the blog posting refered to: most .Net developers don't have a deep knowledge of these issues, which are very important for complex enterprise systems development.

    I don't blame them, it is just a reflection of the priorities that MS gave for RAD tools over all these years. Now that MS decided to face Java on a level field, using the same "weapons", their ex-VB developer base is having a hard time adapting to all these "new paradigms". They now are facing the same complex choices Java developers have faced for years (to cache or not, to cluster or not, to use O/R map or not, and how to implement each of them), but without the years of experience on making these hard decisions.

    They just can't blindly go to MS and ask for the drag-and-drop solutions as before, as you suggested us, simply because there is not a simple answer the these problems, there is not a magic wand that will solve them. Most of MS solutions up to .Net where directed at relatively simple solutions for relatively simple problems, but now with .Net the level of complexity has raised, and the old concepts adopted by MS developers don't fit anymore. If they will be able to catch up with Java developers, only time will tell. But as I said, if that time comes, Java will already be on the "next big thing", so Java community should not be worried about it.

    I suggest you to read the marvelous Martin Fowler's book titled "Patterns of Enterprise Application Architecture", I am sure some of your concepts regarding those 4 subjects will be thrown away at the first pages... ;)

    Regards,
    Henrique Steckelberg
  33. Let us just for a moment accept your statement that all MS developers are stupid former VB irresponsible hobbyists - Microsoft hackers!

    In that case remember:

    First, the default Connection Pooling settings for the .NET Data Provider for SQL Server allows hundreds of thousands of customers per day- without any COM, EJB, CORBA, O/R Mapping, complex clustering session management, expensive caching tools et al.

    Then, don't you trust that the management in larger projects would be sure to hire a sufficient qualified team?

    ____________________________

    Sometimes in the future you too will realize the "comique" of forcing down the whole J2EE shebang even in the smallest of projects.

    And finally think about that the whole market of Enterprise application development is going in the direction of SOA and Rich-Clients; ponder what that mean to J2EE.

    Regards
    Rolf Tollerud
  34. Let us just for a moment accept your statement that all MS developers are stupid former VB irresponsible hobbyists - Microsoft hackers!


    I didn't state that. I am just making assumptions about a great proportion of .Net developers in .Net that have come from VB and ASP (and I may be wrong). I am sure there are great developers in .Net, as there are great developers in VB, Java and in any other technology out there. And I am sure there are lame developers in Java too as well, as there are in any other technology.

    >
    > In that case remember:
    >
    > First, the default Connection Pooling settings for the .NET Data Provider for SQL Server allows hundreds of thousands of customers per day- without any COM, EJB, CORBA, O/R Mapping, complex clustering session management, expensive caching tools et al.
    >

    Here you come with MS's magic wand again. Are your sure it will solve every complex enterprise development problem out there? The moment the "default Connection Pooling" in .Net doesn't solve the problem, that's when the good developer will be needed. Is there enough of them with experience in dealing with these situations, whose frequency will only increase with the growth of the complexities of enterprise systems?

    > Then, don't you trust that the management in larger projects would be sure to hire a sufficient qualified team?
    >
    Being .Net such a new technology, it is naturally bound to have scarce resources with great practical experience in the market.

    > ____________________________
    >
    > Sometimes in the future you too will realize the "comique" of forcing down the whole J2EE shebang even in the smallest of projects.
    >
    This is already becoming past right now, Rolf, better find another excuse: most J2EE developers have learned where better to apply each solution, it is called experience. Besides, there's lightweigth frameworks, AOP and other solutions appearing that will make this history for sure.

    > And finally think about that the whole market of Enterprise application development is going in the direction of SOA and Rich-Clients; ponder what that mean to J2EE.

    Well, going back to "client-server" would really be best for MS. That's the kind of field they have dominated for years, what most (read again: most, not all) of their developer base have experience with up to now, and which they would surely like to maintain. But Rich-client platform-independent internet won't be here so soon, if ever, and SOA is not a problem for J2EE, which already has all the components to enable it.

    Regards,
    Henrique Steckelberg
  35. better to be on the safe side

    Well Henrique, we can at least agree upon one thing! If I was manager for a large 5 million dollar .NET project I would be sure to have a bunch of Java developers on my team :) Remember the guy (was it in Australia?) who won a MS programming competition with only a couple of days experience with C#..

    hi hi

    Regards
    Rolf Tollerud
  36. better to be on the safe side

    >
    > Well Henrique, we can at least agree upon one thing! If I was manager for a large 5 million dollar .NET project I would be sure to have a bunch of Java developers on my team :) Remember the guy (was it in Australia?) who won a MS programming competition with only a couple of days experience with C#..
    >
    > hi hi
    >
    > Regards
    > Rolf Tollerud

    The fact that .Net has "copied" much of its concepts from Java really can be to its benefit from this point of view, as MS can leverage on the previous experience from Java developers. We are already seeing this, as lots of Open Source projects originally born in Java are being ported to .Net.

    But the reverse will happen too, one day we will see solutions created for .Net being ported to Java too, being both plataforms so similar. As long as Java community keeps innovating, neither of these would be bad for anyone. As always, competition is good for everybody.

    Regards,
    Henrique Steckelberg
  37. But what I am deadly serious about and against is the attitude and the practices in the J2EE camp.

    Such a vacuous claim without giving evidence. The "J2EE camp" is kicking azz in the n-tier market. Modern e-science backends are almost exclusively Linux, increasingly with J2EE middleware. I suspect the same of any compute-bound industry. Globus freeware, the most popular grid platform, is built on servlets. Installing Linux and J2EE on a large Beowulf cluster doesn't cost a penny for CPU and site licensing. On CNBC last week another talking head mentioned the only way to increase profit in the present economy is to cut cost. What is J2EE's competition doing to reduce fees? How is J2EE's competition comparing to very popular freeware?


    It is my firm opinion that large systems can only be constructed from totally autonomous modules that does not inherit or depend or any common libraries- that totally distrust each other.

    Obviously decoupling is the basis of modern service architecture. The interfaces shouldn't depend on eachother. But the servant implementations can and usually do depend on the availability of other services. A thriving service ecosystem is filled with servants that share eachother's stubs.

    I agree with you that community awareness of autonomic computing is slim, but awareness is climbing fast. IBM is helping establish the concepts. J2EE application developers are likely dealing with decoupled services in the field more than other communities. So your suggestion that we J2EE grunts are more lame at it is ludicrous.

    Jini, JXTA, and Globus are Java freeware frameworks that had distributed service architectures perhaps before .NET. Fresh innovations such as aspects and containers will propel service decoupling even further. Java's experimental community is civilization's incubator of this stuff. Microsoft invented ODBC and SOAP, which are crucial for enterprise integration, but the mindshare now is in the Java scene. Java is what the kids are learning at university. Java runs most of the enterprise freeware. Free enterprise.


    Inside each module you can use OO to your hearts content. What the J2EE camp do wrong IMO, is to try glue too large inter-dependent systems together.

    Do you know that WSDL is headed for objects? Like dude WSDL, SDO, and IoC are converging into one vendor-neutral specification, most likely getting a servlet driven reference implementation. To web services WS-Resource is adding:

    + Instance factories.

    + Lifecycle.

    + Data fields.

    + Peer discovery and monitoring.
  38. Queen Elisabeth’s Summer Cottage[ Go to top ]

    Hi Brian,

    Thank you for the link! I like the expression, "autonomic computing".

    Brian: So your suggestion that we J2EE grunts are more lame at it is ludicrous.

    Hmm..I read the new thread today "WS-Discovery: New spec to allow for devices" today, at the bottom of the page was a link to Mark Baker's bLog,

    I started tracking another Web services metric last night; the number of WS-I members. I'm not expecting this to bare any fruit (i.e. show the expected decline) anytime soon, as that will certainly lag the non-deployment of Web services on the Internet by at least a couple of years. But it'll be interesting to watch.
    http://www.markbaker.ca/2002/09/Blog/2004/02/18#2004-02-ws-discovery

    Have I misunderstood or isn't this a grunt?

    On the other hand when I followed your link about computational grids and I found this course, from National e-Science Centre,

    OGSI and Microsoft.NET

    With the advent of the Open Grid Services Architecture (OGSA) and its underlying infrastructure - the Open Grid Services Infrastructure (OGSI) - there is an increasing interest within Grid communities worldwide in Microsoft .NET Web Services technologies and their applicability to Grid services.
    http://www.nesc.ac.uk/esi/events/369/

    But nowhere can I find Sun involved in anything with WS.

    But seriously this discussion reminds me a little about the sketch "Queen Elisabeth’s Summer Cottage": There are two men at the job, one has just bought a small cabin and the other is envious but just keep harping all the time "Queen Elisabeth, her summer cottage is really something.

    Regards
    Rolf Tollerud
  39. Queen Elisabeth’s Summer Cottage[ Go to top ]

    But nowhere can I find Sun involved in anything with WS.

    Strawman. No one here claimed that Sun is leading web services. The Java tools community however is.

    How's this for gossip?

    ".Net vote rigging illustrates importance of Web services
    ... In December [2002], Java was more popular than .Net for building Web services, according to a ZDNet UK poll, but weeks later the position had dramatically reversed; investigation revealed just what lengths Microsoft will go to to promote its products. ... ZDNet UK logs reveal rather obvious vote rigging, and prove that it originated from within Microsoft..."
    -- http://news.zdnet.co.uk/software/0,39020381,2102244,00.htm
  40. current hot fashions[ Go to top ]

    Come on, shall we listen to gossip now? No mention of Microsoft murder?

    Why should MS manipulate results when all surveys show the same?? - Here is the latest and freshest hot web fashion trend survey, direct from California:

    Westbridge Web Services usage survey
    2004-02-10

    .NET continues to be the most popular tool for Web Services generation. Forty-three percent of respondents have Web Services traffic generated by .NET tools. Java was a close second with 35 percent.

    Only 24 percent said they were not currently moving to an SOA environment.

    http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/02-10-2004/0002106759&EDATE=

    That should be seen in the light that Java still have a 2 to 1 lead for overall Web app development.

    You can download it at,
    http://www.westbridgetech.com/registerP.jsp?c=210

    You do know that orange and turquoise is the colors this summer, do you? And Black Eyed Peas is topping all charts.

    Regards
    Rolf Tollerud
  41. current hot fashions[ Go to top ]

    Rolf (quoting some rag) .NET continues to be the most popular tool for Web Services generation. Forty-three percent of respondents have Web Services traffic generated by .NET tools. Java was a close second with 35 percent.

    Love it! Most companies don't use IIS for external apps, since it's perceived as a huge security hole, but the plurality of "respondents" are doing "Web Services traffic generated by .NET tools." Does that mean that almost no one is actually doing web services? Or rather, does it mean that most of the people using .NET are accidentally using "Web Services" as their RMI? Poor kids.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  42. current hot fashions[ Go to top ]

    Or rather, does it mean that most of the people using .NET are accidentally using "Web Services" as their RMI?

    How sad. It's a handicap to use SOAP on an intranet. How few .NET applications are intended to span firewalls?
  43. J2EE war cry[ Go to top ]

    Now when I have slept on it I can understand the grunting.

    First, I hardly think 100% pure Intranet Web applications exist anymore. At the very least you want to have access when you are off road.
    When you have taken the trouble to put it on the Web Server - why not use it?

    Second, in an Intranet the SOAP/WSDL protocol is slower that RMI of course, but, and I say again but; most Intranet applications is in practice so poorly written (= chatty), that they loose the little advantage they could have had compared to a SOA style implementation.

    So it looks no better than that both CORBA and RMI will have a bleak future in everything but in the very most extremely performance demanding situations where everything possible is done for speed. But wait! - I forgot that that isn't J2EE tour de force anyhow. (with the 10-12 frameworks stacked on top of each other).

    J2EE war cry:
    "hogachacka, hogachacka, one more indirection will solve every problem!"

    Regards
    Rolf Tollerud
  44. I am happy to be quoted![ Go to top ]


    > J2EE war cry:
    > "hogachacka, hogachacka, one more indirection will solve every problem!"

    Heheheheh! Oh I am so happy to be quoted! :) You are my hero, Rolf!

    You may think that phrase is stupid, but again, if you stop and think for a minute... for example: you take a poorly designed Operational System, with a crappy API, with lots of applications written for it. How to decouple them? Put a framework in between the applications and those crappy APIs, and voila! you can scrap the stinky OS and its APIs! Ever seen this before somewhere? ;)

    This "indirection law of computing" is the mother of all patterns! :)

    Regards,
    Henrique Steckelberg

    "the worse kind of blindness is the unwillingness to see"
  45. J2EE war cry[ Go to top ]

    ...most Intranet applications is in practice so poorly written (= chatty)...

    But chatter is cheap in a cluster. Chatty only costs on the extranet.


    ...they loose the little advantage they could have had compared to a SOA style implementation.

    What advantage?


    So it looks no better than that both CORBA and RMI will have a bleak future in everything but in the very most extremely performance demanding situations where everything possible is done for speed. But wait! - I forgot that that isn't J2EE tour de force anyhow.

    That's a pot shot. No claim was made here that Java is suited for High Performance Computing. We're talking about enterprise computing, which isn't compute bound.
  46. Intranet, Extranet , Internet[ Go to top ]

    Yes,yes Brian, I was expression my self poorly. What I was trying to say is that as the security standards is hardening, the distinction between Intranet, Extranet and Internet is blurring. For example, we have just finished an HR application with a lot of sensitive and delicate information about the employees. The customer insisted (despite of already having a tunneling gateway), that the system should be available via Internet.

    Regards
    Rolf Tollerud
  47. Summary java run 28% faster and consumed 4500% more memory.

    If you run the xmlmark_DOM1.ini with following parameters
    -server -verbose:gc -Xloggc:xmlmark_gc_d.log -Xmx1024M
    (no Xms), you will see that the heap stays around 5MB. But when you add up the time spent in GC (by analysing the output in xmlmark_gc_d.log), you see that the application spents around 50% of it's time in the GC.
    Now you can vary the -Xms parameter from 4m to 1024m.
    On my machine the time spent in GC varies then from 50% to 0.5%.
    So the whole point about that memory parameters seems to be to avoid GCs.
    At -Xms40m dotnet and java are about equally fast for this test on my computer.

    BTW dotnet spends about 7-9% time in the GC when using about 8-9MB heapspace.

    The sax3 test seems to have a total different behaviour pattern (I only run a few runs). Others will again look different.
  48. Childish[ Go to top ]

    This sort of stuff is pretty childish. Best to save away to be trotted out when MS next decides to piss FUD everywhere.
  49. Java Webservice ( Weblogic 8.1) is faster than .Not at least 30% to 50%.
    We found lot of time outs on the .Net Webservice... M$ should tone down their
     .Not webservice hype.
  50. is that so[ Go to top ]

    Jamie: M$ should tone down their .Not webservice hype

    Discover SOAP encoding's impact on Web service performance
    Radically improve performance by changing your encoding style

    Frank Cohen CEO
    www.pushtotest.com/ptt
    Published by IBM
    http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/#resources

    >"Recent study of SOAP encoding styles showed a 30-fold performance improvement by choosing SOAP document-style encoding over SOAP-RPC".

    >"SOAP RPC encoding is easiest for the software developer; however, all that ease comes with a scalability and performance penalty. SOAP RPC-literal encoding is more involved for the software developer to handle XML parsing, but requires less overhead from the SOAP stack. SOAP document-literal encoding is most difficult for the software developer, but consequently requires little SOAP overhead".

    >"Most of the SOAP tools on the Java platform default to SOAP RPC encoding styles. For example, with IBM WebSphere Studio Application Developer, the default encoding style is set to SOAP RPC. On the other side of the divide, .NET development tools implement document-style SOAP calls by default".

    Regards
    Rolf Tollerud
  51. is that so[ Go to top ]

    Jamie: M$ should tone down their .Not webservice hype

    >
    > Discover SOAP encoding's impact on Web service performance
    > Radically improve performance by changing your encoding style
    >
    <blah></blah>
    >
    > Regards
    > Rolf Tollerud

    So actually when WebLogic uses a slower form of SOAP than .Net, WebLogic is still 30% to 50% faster? Interesting...
  52. use it daily[ Go to top ]

    Do you not think that it should be at least one prerequisite for statements not backed by fact: namely, that you believe it yourself? Why don’t you download the excellent little -AmberPoint Express- Web Services monitoring tool from
    http://express.amberpoint.com/expressonline/users/Home.xhtml and test your Apache Tomcat/Axis server, versions soon coming for other Java servers.

    I hold my breath to get the versions for WebSphere and WebLogic!

    Regards
    Rolf Tollerud
  53. use it daily[ Go to top ]

    Do you not think that it should be at least one prerequisite for statements not backed by fact: namely, that you believe it yourself? Why don’t you download the excellent little -AmberPoint Express- Web Services monitoring tool from

    > http://express.amberpoint.com/expressonline/users/Home.xhtml and test your Apache Tomcat/Axis server, versions soon coming for other Java servers.
    >
    > I hold my breath to get the versions for WebSphere and WebLogic!
    >
    > Regards
    > Rolf Tollerud

    First, it was not an statement, but a question. Second, you stated that Java Server implementations default to a slower form of SOAP encoding when compared to .Net's default encoding. Given that our friend Jamie Schiner has seen WebLogic 30% to 50% faster than .Net regarding WS calls in a practical situation... you can draw conclusions for yourself, it's not difficult. Just don't let Bill Gates drive your neurons this time! ;)
  54. WSDL body use, SOAP binding style.[ Go to top ]

    Discover SOAP encoding's impact on Web service performance
    Radically improve performance by changing your encoding style


    I agree that would be so on a LAN, which is a silly arena for WSDL. But performance on a wide area network is dominated by latency, which is unnaffected by encoding/style.

    I dig the IBM link you gave, and suggest another:
    http://www-106.ibm.com/developerworks/webservices/library/ws-whichwsdl

    It says that RPC/encoded is the only way to serialize graphs. Graphs are important since (as Sun's JAX-RPC tutorial notes) a wide area network favors a bulky message bearing complex data.

    SOAP RPC-literal encoding is more involved for the software developer to handle XML parsing...

    Not so. Apache Axis automates RPC/literal as much as RPC/encoded.
  55. WSDL body use, SOAP binding style.[ Go to top ]

    Hi Brian,

    Thank you for the link!
    Brian: RPC/encoded is the only way to serialize graphs..

    True but it is also true that he says that document/literal is usually the best approach.

    Russell Butek: So far, this article has given the impression that the document/literal wrapped style is the best approach. Very often that's true. But there are still cases where you'd be better off using another style

    And here is more of the same thing.
    RPC/Literal and Freedom of Choice by Yasser Shohoud,
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/rpc_literal.asp

    But of course there are always exceptions. Personally I hate the automatic serialization and deserialization feature. For mapping XML to objects I would much rather serialize by hand and write my own XML- then there would be no problem with Hashtables or collections! BTW, how do you return datasets? I am considering a drastic method but I would like to hear a second opinion.

    Regards
    Rolf Tollerud
  56. WSDL body use, SOAP binding style.[ Go to top ]

    Personally I hate the automatic serialization and deserialization feature. For mapping XML to objects I would much rather serialize by hand and write my own XML...

    Maybe you dig the control. But we in the mainstream deserve simplicity via automation. We don't care about wire format -- we care about effort and time-to-market. Eg, I assumed my latest project was RPC/encoded, but I just checked, and I was accidentally using RPC/literal without even knowing. The wire format just doesn't matter. At least with RPC/encoded we get closest to the behavior of Java serialization. I've surveyed WSDL from several e-science projects, and most folks lazily use RPC/encoded since the tool chain is the most seemless and easiest. Only the ivory tower dudes practice and preach other encodings. You probably write WSDL and XSD by hand. Yuk!

    ...then there would be no problem with Hashtables or collections! BTW, how do you return datasets?

    The easiest way seems to be using an array to bear collection contents. Even a map can be shoe-horned into an array(s). It's pathetic that JAX-RPC and Axis don't automate collections.
  57. Java 5.0 (1.5) vs .net 2.0[ Go to top ]

    I down loaded the bench marks to see the performance on the current beta versions.


    I updated the .net version to 2.0 specs, and a saw a modest perfornace as compared to the 1.1 spec results.

    To be fair I'm not a java expect so I didn't do anything other then compile the existing bench marks using the beta 5.0 jdk. I did attempt to run using the -server jvm, but I would get an error. Is the server mode still supported on 5.0? If so how do I use it. Also, I wasn't aware of any "best paratices" sun is advocating concerning xml programming with the 5.0 JDK, but if any recomendations exist let me know.

    As stated, updated the .net bench marks to 2.0 specs,
    which consisted of the following:

    Using XPathEditor, instead of XDocument.
    Using XSchemaSet, instead of XSchemaCollection.

    Notes, Moving to XPathEditor did have a big impact

    Anyway heres the performance numbers on getting on my system:
    HP 2.8 GHZ Xp system.

    Java jdk 5.0 Results:
    0.0, 100.0, 25.0, 0.0, 0.0, 0.0, 0.0, 108.85, 94529,
    4, 0.0, 100.0, 25.0, 0.0, 0.0, 0.0, 0.0, 127.64, 94529
    4, 0.0, 100.0, 50.0, 0.0, 0.0, 0.0, 0.0, 110.30666, 94529
    4, 0.0, 100.0, 100.0, 0.0, 0.0, 0.0, 0.0, 101.9, 94529,
    4, 0.0, 100.0, 50.0, 0.0, 25.0, 0.0, 100.0, 111.74, 94529,
    4, 0.0, 100.0, 50.0, 0.0, 0.0, 25.0, 100.0, 98.60333, 94529,
    4, 0.0, 100.0, 50.0, 0.0, 25.0, 25.0, 100.0, 95.32667, 94529,
    4, 100.0, 0.0, 25.0, 0.0, 0.0, 0.0, 0.0, 94.113335, 905430,
    4, 100.0, 0.0, 50.0, 0.0, 0.0, 0.0, 0.0, 50.63, 905430,
    4, 100.0, 0.0, 100.0, 0.0, 0.0, 0.0, 0.0, 23.65, 905430,

    .Net 2.0 (1.1 specs) Results:
    04, 00, 100, 50, 00, 00, 00, 00, 139.07330, 94529,
    04, 00, 100, 100, 00, 00, 00, 00, 129.06330, 94529,
    04, 00, 100, 50, 00, 25, 00, 100, 79.63000, 94529,
    04, 00, 100, 50, 00, 00, 25, 100, 57.65333, 94529,
    04, 00, 100, 50, 00, 25, 25, 100, 48.93333, 94529,
    04, 100, 00, 25, 00, 00, 00, 00, 240.11330, 905430,
    04, 100, 00, 50, 00, 00, 00, 00, 120.84000, 905430,
    04, 100, 00, 100, 00, 00, 00, 00, 62.07333, 905430,

    .Net 2.0 (2.0 specs) Results:
    04, 00, 100, 25, 00, 00, 00, 00, 196.36000, 94529,
    04, 00, 100, 25, 00, 00, 00, 00, 192.73000, 94529,
    04, 00, 100, 50, 00, 00, 00, 00, 162.97000, 94529,
    04, 00, 100, 100, 00, 00, 00, 00, 131.21330, 94529,
    04, 00, 100, 50, 00, 25, 00, 100, 104.46670, 94529,
    04, 00, 100, 50, 00, 00, 25, 100, 116.47000, 94529,
    04, 00, 100, 50, 00, 25, 25, 100, 102.19000, 94529,
    04, 100, 00, 25, 00, 00, 00, 00, 245.68330, 905430,
    04, 100, 00, 50, 00, 00, 00, 00, 123.56670, 905430,
    04, 100, 00, 100, 00, 00, 00, 00, 58.45667, 905430,
  58. Didn't mean to post the previous reply just yet.
    Anyway, the 1.1 spec version of the DOM .net benchmark out performaned the
    java version on read operations, but was slower on the writer operations.
    As reported by Microsoft moving away from the DOM (ie XDocument) to optimized XPathNavigator (XPathNaviagtor now supports editing via XPathEditableNavviator), had a signficant improvement on all operations, but was only sighly faster then the java version on the lagest edit benchmark.

    The bigest surprise was the results showing the .net 2.0 xml reader/writers to be signficant more preformant then the JDK 5.0 SAX api's, despite sun's claim as to the advantages of pull vs push parsers.

    Does anyone else have results using the latest beta's?

    Heres the results of running the .net binary as provided in the down load.
    I'm assuming it was complied with 1.1.

    04, 00, 100, 25, 00, 00, 00, 00, 69.60667, 94529,
    04, 00, 100, 50, 00, 00, 00, 00, 70.34333, 94529,
    04, 00, 100, 100, 00, 00, 00, 00, 68.19000, 94529,
    04, 00, 100, 50, 00, 25, 00, 100, 49.77333, 94529,
    04, 00, 100, 50, 00, 00, 25, 100, 34.40667, 94529,
    04, 00, 100, 50, 00, 25, 25, 100, 24.38000, 94529,
    04, 100, 00, 25, 00, 00, 00, 00, 69.08667, 905430,
    04, 100, 00, 50, 00, 00, 00, 00, 34.77667, 905430,
    04, 100, 00, 100, 00, 00, 00, 00, 17.79333, 905430,

    Also, the first entry from the 1.1 specs was missing from the pervious post was missing.
    Here it is:
    04, 00, 100, 25, 00, 00, 00, 00, 148.19670, 94529
  59. .Net faster than Java ?[ Go to top ]

    No, no - It cant be !!
  60. Electric XML?[ Go to top ]

    What about Electric XML? Or is that the past? I just found out that TheMindElectric has been taken by webMethods. But I couldn't find the Electric XML package. I remember the Electric XML package is very fast in parsing XML, can it beat the mentioned results?

    Regards,

    Mark Monster
  61. as expected[ Go to top ]

    I all the time expected MS .Net to do better than java/j2ee, the contrary would be a real shame for an application that is developped by numberone software company and that has copied all the best available tachnologies.

    now when I read that java does quite as well (sometimes better!!) I realise that eventhaugh rough performance was not our primary goal we are rewarded with acceptable performance.

    with this said we have overcome some performance issues with just some oracle tricks and rethinking of the exchanged data.

    best of all we use proprietary and free software that we think is better (eclipse, cvs, oracle, jboss, toad, linux ...)

    I really don't see M$ .NET in our environement any soon ...