Michael Teske
2008-11-06 22:57:29 UTC
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
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