[tao-users] OmniORB - TAO performance comparison with tremendous differences
Marciniak, Zbigniew
Hello
recently we have compared latest versions of OmniORB and TAO by running a simple client/server example.
This example consists of a list of trivial setter functions.
short set_short(in short value);
long set_long(in long value);
float set_float(in float value);
double set_double(in double value);
boolean set_boolean(in boolean value);
char set_char(in char value);
string set_string(in string value);
octet set_octet(in octet value);
any set_any(in any value);
Object set_Object(in Object value);
long set_shortSeq(in shortSeq value);
long set_longSeq(in longSeq value);
long set_floatSeq(in floatSeq value);
long set_doubleSeq(in doubleSeq value);
long set_booleanSeq(in booleanSeq value);
long set_charSeq(in charSeq value);
long set_stringSeq(in stringSeq value);
long set_octetSeq(in octetSeq value);
long set_anySeq(in anySeq value);
long set_ObjectSeq(in ObjectSeq value);
which were called 1000 times in a loop. We have used both ORBs as-is without any tuning, just like they are downloaded. We compiled TAO in release, not debug, version. The same source code was compiled with both ORBs.
We have got the following results on 2 Linux PCs (first was Pentium 4, 1.6GHz, 512MB and second Pentium 4, 2.40GHz, 512MB) connected via 100 Mbit Ethernet:
datatype ms
TAO OmniORB
short 345 115
long 341 114
boolean 341 115
char 344 116
string 351 161
octet 342 114
any 450 154
object 356 122
short seq. 350 118
long seq. 350 118
float seq. 350 120
double seq. 350 156
boolean seq.347 118
char seq. 354 118
string seq. 378 134
octet seq 356 118
any seq 348 116
On windows computers the results were as follows (first Dual-Xeon (550 MHz, 1 GB, Win.NT4) and
second Pentium III (1GHz, 256 MB, Win.XP) connected via 100 Mbit Ethernet):
datatype ms
TAO OmniORB
short 643 590
long 656 506
boolean 701 513
char 641 514
string 668 585
octet 695 520
any 710 606
object 665 541
track 698 566
short seq. 639 559
long seq. 698 531
float seq. 671 537
double seq. 642 535
boolean seq.731 508
char seq. 634 488
string seq. 682 571
octet seq 692 528
any seq 666 570
track seq. 877 664
This was an surprise since we discovered that TAO was much (average 25% on windows and sometimes even 300% on Linux) slower than OmniORB. Since TAO is considered to be fast I am wandering where we made a mistake. Can somebody give me a hint how to make TAO programs faster.
I guess we are not best CORBA programmers so I hope we have made a simple mistake.
However we treated OmniORB and TAO equally (same source code) and therefore we cannot understand these huge differences for the OmniORB advantage.
Is perhaps OmniORB indeed much faster?
Best regards
Zbigniew
Alexander Jasper
> Hello
>
> recently we have compared latest versions of OmniORB and TAO by
> running a simple client/server example.
> This example consists of a list of trivial setter functions.
>
[...]
> This was an surprise since we discovered that TAO was much (average
> 25% on windows and sometimes even 300% on Linux) slower than OmniORB.
> Since TAO is considered to be fast I am wandering where we made a
> mistake. Can somebody give me a hint how to make TAO programs faster.
>
> I guess we are not best CORBA programmers so I hope we have made a
> simple mistake.
>
> However we treated OmniORB and TAO equally (same source code) and
> therefore we cannot understand these huge differences for the OmniORB
> advantage.
>
> Is perhaps OmniORB indeed much faster?
>
Hi Marciniak!
in its default configuration TAO is optimized for scalability, not raw
performance for one client and per server. The options in question are
described in ACE_wrappers/TAO/docs/performance.html. I did also measure
the call latency but I can not remember how much difference changing
these options made.
hope this helps
Alexander
Douglas C. Schmidt
Hi Zbigniew,
> recently we have compared latest versions of OmniORB and TAO by
> running a simple client/server example.
It's not clear what you mean by "later versions," so please
make sure you fill out the appropriate problem report form (PRF),
which is in
$ACE_ROOT/PROBLEM-REPORT-FORM
$TAO_ROOT/PROBLEM-REPORT-FORM
when asking reporting anything about ACE+TAO since otherwise we have
to "guess" what version/platform/compiler/options you've using, which
is very error-prone and slows down our responsiveness. The
forthcoming TAO 1.4 release (due out at the end of December 2003) has
been optimized so that it should run faster than versions based on the
TAO 1.3 baseline. I recommend you check with Bala
<ba...@dre.vanderbilt.edu> for more information on what sorts of
improvements you can expect.
Thanks,
Doug