[omniORB-dev] CORBA::string_dup

David Riddoch david at riddoch.org.uk
Mon Oct 6 18:57:33 BST 2003


Hi,

I suspect you'll find that the relative performance depends on the size 
of string you are using.  memcpy() is generally optimised for moderate 
to large copies, whereas I suspect that strcpy() is optimised for small 
strings.  I think you use 1024-byte strings in your comparison.

For shortish strings I would expect strcpy() to be faster than 
strlen()+memcpy() because it only has to make one pass over the data. 
For long strings, the memcpy() version is likely to be faster, since it 
can burst read and write large chunks of data at a time.  (And large 
data copies are typically write-bandwidth limited).

However, in the case of CORBA::string_dup() we have to determine the 
string length first in order to performance the allocation.  Given this, 
I would expect an implementation using memcpy() to be faster than 
strcpy() in most cases.

Cheers,
David


Serguei Kolos wrote:
> Duncan Grisby wrote:
> 
>>On Friday 26 September, Serguei Kolos wrote:
>>
>>>I have noticed that the CORBA::string_dup function uses strcpy to copy 
>>>strings.
>>>Unfortunately on many systems strcpy is much slower then for example 
>>>memcpy.
>>>For example on Linux (RedHat 7.3) the strcpy is 5 (sic!) times slower. 
>>
>>Really?  Wow!  I wonder what it's doing.
>>
>>>What do you think about the idea of using the memcpy in the
>>>CORBA::string_dup instead of the strcpy? Are there any drawbacks
>>>with the memcpy?
>>
>>I suspect that on other platforms memcpy might be slower than strcpy.
>>
> I have tested on Solaris 5.7 with SunPro 5.2. The memcpy is still faster 
> then strcpy (bu not so dramatic
> as on Linux).
> 
>>
>>Something to try is to replace the call with the obvious for loop.
>>Between omniORB 3 and 4 I did some profiling and found that strcmp was
>>stupidly slow, and by far the fastest thing was an inline function
>>with a for loop. It will probably be the same with strcpy.
>>  
>>
> I have tested this also and found that the for loop solution is not 
> always faster in
> case of strcpy and strlen (on Solaris for example). It depends on 
> OS/compiler.
> I attached simple program that makes timing for various strdup 
> implementations.
> You can see that the fastest one is always system strdup, but as far as 
> I know
> the strdup is not available on all the platforms. But note also a 
> difference between strcpy
> and memcpy.
<snip>




More information about the omniORB-dev mailing list