[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jacorb-developer
Subject:    Re: [jacorb-developer] Performance of Jacorb over time....
From:       Andre Spiegel <spiegel () gnu ! org>
Date:       2005-02-01 21:18:37
Message-ID: 1107292717.24697.105.camel () localhost
[Download RAW message or body]

On Tue, 2005-02-01 at 11:32 -0500, Gautam H. Thaker wrote:

> I maintain a website where we track performance of about a dozen ORBs.

Thanks for posting it; this is good and very valuable information.

> Considering 4 byte payload latencies, one observes the following progression:
> 
> JacORB Version        Latency                Date           JDK
> 1.3.30                  543 msec            Nov. 2001       1.3.1
> 1.4.1                   838 msec            Feb. 2003       1.4.1
> 2.0                     661 msec            Jan. 2004       1.4.2
> 2.2.1                   807 msec            Jan. 2005       1.4.2

I can't speak for 1.4.1, but there have been significant changes in the
ORB core for 2.0, to support AMI and QoS policies (timeouts).  Before
the 2.0 release, we did explicit performance testing to ensure it
wouldn't have negative impact.  Looks like we more than achieved this
goal.  (I don't know how many other ORBs can be compared to that; I
wonder how many of them do support AMI and QoS yet.)

For 2.1, ETF was introduced (we were the first Java ORB to actually
implement the draft standard), and this meant significant modifications
within the ORB core as well.  In 2.2, the new configuration framework
was introduced (allowing for several ORBs in the same JVM with different
configurations) -- again a significant change.

We are aware that another round of performance optimization is called
for, but given that we are still faster than the old-and-trusted 1.4.1
version, I'd say the situation is not too bad.

Does that explain it?  Thanks indeed for posting the results, it's
always nice to have an independent tester watching :)




[prev in list] [next in list] [prev in thread] [next in thread]