Major performance improvements in BEA Workshop 10.2

Discussions

News: Major performance improvements in BEA Workshop 10.2

  1. BEA Workshop 10.2, BEA's Eclipse-based development environment, is here and it's faster than ever. Developers will experience noticeable speed improvements in server start, deployment, incremental, and clean build, and the stability of 885+ resolved software defects. This release updates BEA Workshop for WebLogic, BEA Workshop Studio with Adobe Flex Builder 2, and BEA Workshop for JSP. Also, the tuxedo control is back, and is shipping with this release. For anyone unfamiliar with the WorkSpace Studio Laucher initiative, please visit the FAQ on edocs to understand this change. BEA WebLogic Portal 10.2 users will want to check out the new integration with the BEA Workshop Studio WYSIWYG designers, new to this release. [Editor's note: there's a lot of speed improvements in the list below. It's worth asking, since they've taken the time to measure this stuff, how much TSS readers are noticing these things in the field - do speed improvements on this level really affect you? If not, why not? A systemic improvement like this can add up in a real way. Also... it'd be neat to see a comparison like this that crossed IDEs instead of comparing to one prior release.] Here are some highlights of what you'll experience:Performance vs. BEA Workshop 10.1
    • Operations with Sun JVM:
      • Server Start
        • 24%, 22%, 40% improved across tall, grande, and venti applications
      • Deployment
        • From a fresh project deploy a non-trivial application for the first time.
          • 8%, 42%, 73% improved across sml, med, lrg app
        • Add method to and deploy web service
          • 38% improved for large app
        • Add an action to a Page Flow then Run on Server.
          • 2%, 22% improved for medium and large applications
        • Edit Page Flow by adding reference to a Service Control in a utility project then Run on Server.
          • 2%, 30% improved for medium to large applications
    • With Sun JVM doing incremental build
        • Add action to a Page Flow
          • 29%, 41%, 56% improved across small, medium, large application
        • Add method to Web Service
          • 33%, 51%, 55% improved across sml, med, lrg app
        • Edit XMLBean by adding two complex types to schema that reference each other
          • 18%, 43%, 65% improved across small, medium, and large applications
        • Add callback to Web Service
          • 25%, 47%, 65% improved across small, medium, and large applications
      • Clean Build
        • 20.23% improved with large application
    • Operations with JRockit JVM:
      • Server Start
        • 15%, 23%, 25% improved across small, medium, large applications
      • Deployment
        • From a fresh project deploy a non-trivial application for the first time.
          • 9%, 56%, 93% improved across small, medium, large applications
        • Add method to and deploy web service
          • 7%, 71% improved for med, large app
        • Add an action to a Page Flow then Run on Server.
          • 66% improved for large app
        • Edit Page Flow by adding reference to a Service Control in a utility project then Run on Server.
          • 1%, 64% improved for med - large app
    • With JRockit JVM doing incremental build
        • Add action to a Page Flow
          • 38%,90% improved across med, lrg app
        • Add method to Web Service
          • 11%, 50%, 96% improved across med, lrg app
        • Edit XMLBean by adding two complex types to schema that ference each other
          • 33%, 48%, 93% improved across sml, med, lrg app
        • Add callback to Web Service
          • 26%, 40%, 90% improved across sml, med, lrg app

    Threaded Messages (6)

  2. Oracle acquisition of BEA[ Go to top ]

    Is probably more relevant IMO :o) That being said, most of the time any performance problems we see are more from sloppy coding more than anything else. So, no any changes are rarely seen, because the rest is sooooo slooooooooooowwwww. Additionally we when deploy new servers it's on new machines that are usually faster. a++ Cedric
  3. Is probably more relevant IMO :o)
    In my opinion, too. However, BEA is being silent (by mandate!) right now, so there's nothing forthcoming from them on the acquisition yet.
  4. Re: Oracle acquisition of BEA[ Go to top ]

    Is probably more relevant IMO :o)

    That being said, most of the time any performance problems we see are more from sloppy coding more than anything else.

    So, no any changes are rarely seen, because the rest is sooooo slooooooooooowwwww.

    Additionally we when deploy new servers it's on new machines that are usually faster.

    a++ Cedric
    Totally agree. BEA is a beast when comes to performance of their app server. Slow - start up and response times, lots of bugs, crappy coding and bad patches. And also the size it takes up in memory as well as harddisk is so high. Close to 1.5GB to 2GB on harddisk and about a 1GB in RAM. Can someone optimize that? Most of the world uses eclipse or IDEA or net beans for development, so no point in improving workshop. Improve your server.
  5. Re: Oracle acquisition of BEA[ Go to top ]

    BEA is a beast when comes to performance of their app server.
    Slow - start up and response times, lots of bugs, crappy coding and bad patches.
    And also the size it takes up in memory as well as harddisk is so high. Close to 1.5GB to 2GB on harddisk and about a 1GB in RAM.
    Can someone optimize that? Most of the world uses eclipse or IDEA or net beans for development, so no point in improving workshop. Improve your server.
    Well... Workshop is based on Eclipse, so it sort of dovetails into what you're saying. Improvements to Workshop are improvements for Eclipse. BTW, you're aware that BEA is a sizeable company, right? I mean, they do have enough people to work on workshop and weblogic at the same time... and even other projects as well. I don't think that throwing everyone on one project is all that beneficial.
  6. Of course you can assign all of your staff to one project, after-all, can't 9 women make a baby in a month? As far as the size and weight of the application server, I can't say that I agree with you on performance metrics. This tells me that you've never worked in a fully loaded JBoss environment (read "the ALL server") or you've never dealt with RAD/RUP/WebSphere. Work with either of those long enough as a developer and then come back and tell me what a slow, clunky POS WebLogic is. You'll think its a 100 times better than you do now.
  7. Workshop > RAD[ Go to top ]

    Of course you can assign all of your staff to one project, after-all, can't 9 women make a baby in a month?

    As far as the size and weight of the application server, I can't say that I agree with you on performance metrics. This tells me that you've never worked in a fully loaded JBoss environment (read "the ALL server") or you've never dealt with RAD/RUP/WebSphere. Work with either of those long enough as a developer and then come back and tell me what a slow, clunky POS WebLogic is. You'll think its a 100 times better than you do now.
    Truth on the Internet! If any of you have ever worked with RAD and WAS you know you need about 3GB these days to be able to work ok. I've developed with Workshop before and never really had any of the performance problem listed here. I had a small Dell Latitude with about 2GB of memory.