[omniORB] performance problem increasing sequence length in a loop

Michael Teske subscribe at teskor.de
Thu Nov 6 17:57:21 GMT 2008


Hello!

We're trying (again) to port our system from Orbacus to omniORB. Unfortunately we
have lots of code where sequences are resized dynamically, sometimes even in a
loop (I know this is not the best style, but to find all these locations could
become a nightmare).
While something like this is very fast in Orbacus it becomes very slow in omniORB.
I think this isbecause Orbcaus doubles the reserved buffer if the new desired
length is lower than the old length * 2, while omniORB just allocates the new
length and copies the old sequence over *every* time.

To make my point clear, here's a test program:


---- snip ----

#ifdef USE_OMNIORB
#include <omniORB4/CORBA.h>
#else
#include <OB/CORBA.h>
#endif

#include <iostream>

typedef void (*testfunc)(void) ;

void timetestfunc(testfunc fun, const char * message )
{
  clock_t start = clock();
  fun();
  clock_t stop = clock();
  std::cout << message << " took " << (stop-start) / (CLOCKS_PER_SEC / 1000) <<
"ms \n";
}

long prealloc = 0;
void sequencetest()
{
  CORBA::StringSeq_var ret = new CORBA::StringSeq(prealloc);
  for (int i = 0; i < 40000; i++) {
    long index =  ret->length();
    ret->length(index+1);
  }
}

int main(void)
{
  prealloc = 0;
  timetestfunc(sequencetest, "sequencetest_no_prealloc");
  prealloc = 40000;
  timetestfunc(sequencetest, "sequencetest_prealloc = 40000");

  return 0;
}


---- snip ----


Output omniorb:
sequencetest_no_prealloc took 7090ms
sequencetest_prealloc = 40000 took 0ms

output orbacus:
sequencetest_no_prealloc took 10ms
sequencetest_prealloc = 40000 took 0ms

this was on linux on a 2,8 GHz single-core i86.

The effect is even bigger on self-defined sequences.

Are there any plans to change this or do I have to live with that?
Or, if just nobody bothered yet, are there any reasons not to change this
allocation strategy? If not I would consider writing a patch...

Greetings,
  Michael








More information about the omniORB-list mailing list