FASTER string copy ????

[akarui.tomodachi]

I have two structure definitions as below:

typedef struct _sourceString
{
char firstSourceStri ng[20];
char secondSourceStr ing[20];
char thirdSourceStri ng[20];
}sourceString;
typedef struct _destinString
{
char firstDestinStri ng[20];
char secondDestinStr ing[20];
char thirdDestinStri ng[20];
}destinString;

in the code.......
/*************** *****
sourceString* mySource;
destinString* myDestin;

mySource->firstSourceStr ing = "ABC 123";
mySource->secondSourceSt ring = "ABC 123";
mySource->thirdSourceStr ing = "ABC 123";

strcpy(myDestin->firstDestinStr ing, mySource->firstSourceStr ing);
strcpy(myDestin->secondDestinSt ring, mySource->secondSourceSt ring);
strcpy(myDestin->thirdDestinStr ing, mySource->thirdSourceStr ing);
*************** *******/

The above "strcpy" is ok until I ported this code to a small embedded
system, where TIME is a critical factor. This type of copying by using
"strcpy" takes longer process time and creates all bunch of problems
related to delay.

However, how can I copy my source strings to the destination string
buffers without using strcpy (or memcpy) faster ?

[Richard Heathfield]

ak************* *@gmail.com said:

However, how can I copy my source strings to the destination string
buffers without using strcpy (or memcpy) faster ?

If you can beat a platform-optimised memcpy, you'll be doing *really* well.
The memcpy function is generally optimised to the hilt.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Eric Sosman]

ak************* *@gmail.com wrote:

I have two structure definitions as below:

typedef struct _sourceString
{
char firstSourceStri ng[20];
char secondSourceStr ing[20];
char thirdSourceStri ng[20];
}sourceString;
typedef struct _destinString
{
char firstDestinStri ng[20];
char secondDestinStr ing[20];
char thirdDestinStri ng[20];
}destinString;
Seems rather silly to have two different struct types
with identical content. Not illegal, just silly.
in the code.......
/*************** *****
sourceString* mySource;
destinString* myDestin;

mySource->firstSourceStr ing = "ABC 123";
This is an error in Standard C: the l.h.s. is an array,
and arrays are not assignable. If your compiler accepted
this, it is operating in some kind of "pseudo-C" mode.
mySource->secondSourceSt ring = "ABC 123";
mySource->thirdSourceStr ing = "ABC 123";

strcpy(myDestin->firstDestinStr ing, mySource->firstSourceStr ing);
strcpy(myDestin->secondDestinSt ring, mySource->secondSourceSt ring);
strcpy(myDestin->thirdDestinStr ing, mySource->thirdSourceStr ing);
*************** *******/

The above "strcpy" is ok until I ported this code to a small embedded
system, where TIME is a critical factor. This type of copying by using
"strcpy" takes longer process time and creates all bunch of problems
related to delay.

However, how can I copy my source strings to the destination string
buffers without using strcpy (or memcpy) faster ?

I have no idea. If your code is really as you have shown,
the language you are using isn't C and I cannot tell what the
program is doing. And if your code *isn't* as you have shown,
well then, I *still* cannot tell what the program is doing!

... besides which, the C language says nothing about the
speeds of various constructs, and the speeds (both absolute and
relative) will vary from one implementation to another. The only
reliable way to determine the speed of some operation is to
measure how long it takes -- and keep in mind that the measurement
is only valid on the system where you made it, with the compiler
version and flags that you used, and in the program where you
used them. Change anything, and your measurements become suspect
if not completely invalid.

--
Eric Sosman
es*****@acm-dot-org.invalid

[suresh]

ak************* *@gmail.com wrote:

I have two structure definitions as below:

typedef struct _sourceString
{
char firstSourceStri ng[20];
char secondSourceStr ing[20];
char thirdSourceStri ng[20];
}sourceString;
typedef struct _destinString
{
char firstDestinStri ng[20];
char secondDestinStr ing[20];
char thirdDestinStri ng[20];
}destinString;

in the code.......
/*************** *****
sourceString* mySource;
destinString* myDestin;

mySource->firstSourceStr ing = "ABC 123";
Compiler error : Not an L value
Undefined behavior : Un initialised pointer accessed.
mySource->secondSourceSt ring = "ABC 123";
ditto
mySource->thirdSourceStr ing = "ABC 123";
ditto

Post the original (minimal compilable) code.

strcpy(myDestin->firstDestinStr ing, mySource->firstSourceStr ing);
strcpy(myDestin->secondDestinSt ring, mySource->secondSourceSt ring);
strcpy(myDestin->thirdDestinStr ing, mySource->thirdSourceStr ing);
*************** *******/

The above "strcpy" is ok until I ported this code to a small embedded
system, where TIME is a critical factor. This type of copying by using
"strcpy" takes longer process time and creates all bunch of problems
related to delay.

However, how can I copy my source strings to the destination string
buffers without using strcpy (or memcpy) faster ?

I dont think you can write a function that is faster than what the
compiler provides for this case. You can avoid the call to strcpy by
just assigning the structures.

*myDestin = *mySource

This may not be efficient because it will copy all the contents in one
structure to the other. Whereas strcpy copies only the characters up to
NUL.

If you want more efficient code consider redesigning. Try avoiding
unnecessary copies and the like.

[William Ahern]

On Thu, 16 Mar 2006 20:34:05 -0800, akarui.tomodach i wrote:

The above "strcpy" is ok until I ported this code to a small embedded
system, where TIME is a critical factor. This type of copying by using
"strcpy" takes longer process time and creates all bunch of problems
related to delay.

However, how can I copy my source strings to the destination string
buffers without using strcpy (or memcpy) faster ?

memcpy() will likely be the fastest way you could copy anything to
anywhere for general purpose opaque data.

What's even faster than copying with memcpy() is not copying at all,
so called "zero-copy". With that methodology you simply pass pointers to
your buffers around. It's rather difficult to do, though, especially if
your design didn't incorporate the notion from the beginning. When you
start contemplating reference counting or some such device it's probably
too late in the design cycle (unless the purpose of the device is
specific, and the scope of use limited).

The simper way is for ownership of the buffer to implicitly pass to the
various functions, but that requires careful attention to the flow of
logic.

[John Tsiombikas (Nuclear / Mindlapse)]

On 2006-03-17, Richard Heathfield <in*****@invali d.invalid> wrote:

If you can beat a platform-optimised memcpy, you'll be doing *really* well.
The memcpy function is generally optimised to the hilt.

Not always true. For example, I've done some programming on the nintendo
gameboy advance, and the memcpy() provided by newlib (an
embedded-oriented libc) when compiled with target=arm-agb-elf does *not*
use the DMA circuitry of the gba. So if you use that, you get much
faster memory copies.

But that's a pathological case, I do agree that in general memcpy tends
to be very optimized, and the best choice.

--
John Tsiombikas (Nuclear / Mindlapse)
nu*****@siggrap h.org
http://nuclear.demoscene.gr/

[Richard Heathfield]

John Tsiombikas (Nuclear / Mindlapse) said:

On 2006-03-17, Richard Heathfield <in*****@invali d.invalid> wrote:

If you can beat a platform-optimised memcpy, you'll be doing *really*
well. The memcpy function is generally optimised to the hilt.

Not always true. For example, I've done some programming on the nintendo
gameboy advance, and the memcpy() provided by newlib (an
embedded-oriented libc) when compiled with target=arm-agb-elf does *not*
use the DMA circuitry of the gba. So if you use that, you get much
faster memory copies.

If that is the case, then it isn't platform-optimised. Any fool can write a
/slow/ memcpy:

volatile time_t _lets_waste_tim e;void*memcpy(v oid*t,const void*s,size_t n)
{void*u=t;size_ t i;while(n--){for(i=0;i<n;i ++)_lets_waste_ time=time(NULL) ;
((unsigned char*)t)[n]=((unsigned char*)s)[n];}return u;}

or some such nonsense. This doesn't affect my argument in the slightest.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[John Tsiombikas (Nuclear / Mindlapse)]

On 2006-03-17, Richard Heathfield <in*****@invali d.invalid> wrote:

John Tsiombikas (Nuclear / Mindlapse) said:

On 2006-03-17, Richard Heathfield <in*****@invali d.invalid> wrote:

If you can beat a platform-optimised memcpy, you'll be doing *really*
well. The memcpy function is generally optimised to the hilt.

Not always true. For example, I've done some programming on the nintendo
gameboy advance, and the memcpy() provided by newlib (an
embedded-oriented libc) when compiled with target=arm-agb-elf does *not*
use the DMA circuitry of the gba. So if you use that, you get much
faster memory copies.

If that is the case, then it isn't platform-optimised. Any fool can write a
/slow/ memcpy:

volatile time_t _lets_waste_tim e;void*memcpy(v oid*t,const void*s,size_t n)
{void*u=t;size_ t i;while(n--){for(i=0;i<n;i ++)_lets_waste_ time=time(NULL) ;
((unsigned char*)t)[n]=((unsigned char*)s)[n];}return u;}

or some such nonsense. This doesn't affect my argument in the slightest.

I didn't say it does. I just said that in general what you said is true,
and memcpy is indeed optimized "to the hilt" as you put it, but there
are cases where the memcpy provided might not be platform-optimized, and
it would be a good idea for one to check that first, if memory copy
speed is essential.

--
John Tsiombikas (Nuclear / Mindlapse)
nu*****@siggrap h.org
http://nuclear.demoscene.gr/

[Richard Heathfield]

John Tsiombikas (Nuclear / Mindlapse) said:

On 2006-03-17, Richard Heathfield <in*****@invali d.invalid> wrote:

This doesn't affect my argument in the slightest.

I didn't say it does. I just said that in general what you said is true,
and memcpy is indeed optimized "to the hilt" as you put it, but there
are cases where the memcpy provided might not be platform-optimized, and
it would be a good idea for one to check that first, if memory copy
speed is essential.

Yes, fair enough.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[akarui.tomodachi]

Hi Eric,
You are right, I didn't put the proper syntax in assignment to the
string buffer. The excat code is here:

typedef struct _sourceString
{
char firstSourceStri ng[20];
char secondSourceStr ing[20];
char thirdSourceStri ng[20];

}sourceString;

typedef struct _destinString
{
char firstDestinStri ng[20];
char secondDestinStr ing[20];
char thirdDestinStri ng[20];

}destinString;

in the code.......
/*************** *****
sourceString* mySource;
destinString* myDestin;

sprintf(mySourc e->firstSourceStr ing, "%s", "ABC 123");
sprintf(mySourc e->secondSourceSt ring,"%s", "ABC 123");
sprintf(mySourc e->thirdSourceStr ing, "%s", "ABC 123");

strcpy(myDestin->firstDestinStr ing, mySource->firstSourceStr ing);
strcpy(myDestin->secondDestinSt ring, mySource->secondSourceSt ring);
strcpy(myDestin->thirdDestinStr ing, mySource->thirdSourceStr ing);
*************** *******/