By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,194 Members | 817 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,194 IT Pros & Developers. It's quick & easy.

simple assignment of structs vs. memcpy

P: n/a
hello,

please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;

int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
---
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?

thanks,

Mar 10 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
aiooua wrote:
hello,

please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;

int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
---
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?
Performance is outside of the scope of the C standard and differs
significantly between various systems. On the implementations I'm
aware of, there is no noticeable difference in performance, because
equivalent code is generated for both options.

Mar 10 '07 #2

P: n/a
"aiooua" <ai****@gmail.comwrites:
please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;

int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
It's full of syntax errors. If you want to post a code sample, please
try compiling it first, then copy-and-paste it exactly.

Your meaning happens to be clear enough in this case, but in general
you'll save us a lot of time by posting real code.
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?
There's no real reason to assume that either is faster. It's possible
that the assignment might be faster, because the compiler has more
specific information available to it, but if the structure is large
enough the difference is likely to be trivial. The C standard says
nothing about performance.

In most cases, it's best to write code to be as clear as possible, and
worry about optimization only if you find that it's a real problem.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 10 '07 #3

P: n/a
aiooua wrote:
hello,

please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;

int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
---
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?
The C Standard specifies nothing about the efficiency of the output of
a piece of compiled C code. It's the purview of the compiler to
optimise the object code. This involves a lot of trade-offs and is
likely to be specific for a compiler and a machine, and a set of
compiler options.

I would not worry about such micro-optimisations. Clarity of code is
much more important. The program can, and should, be profiled for
speed bottlenecks and then corrective action can be taken from a
variety of angles. One such corrective action might involve using
memcpy for copying large structures, but it's something to be decided
on a case-by-case basis and no generalisations are possible.

Mar 10 '07 #4

P: n/a
"aiooua" <ai****@gmail.comwrote in message
hello,

please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;

int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
---
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?

thanks,
A naive compiler might call memcpy explicitly for the second case, but
generate inline code for the first. However most compilers are not naive and
will inline and optimise small memcpy()s.

Unless the compiler is pervesely written the furxt should never be less
efficient than the last. However personally I always prefer a call to
memcpy(), because it flags "here is a potentially long operation".
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Mar 10 '07 #5

P: n/a
On Mar 10, 4:33 pm, "santosh" <santosh....@gmail.comwrote:
aiooua wrote:
hello,
please consider the following code:
---
typedef lots int; //lots of data.
typedef struct one_{
lots data;
}info;
int main(){
info i1,i2;
i1 = i2; //option 1
memcpy(i1,i2,sizeof(info)); //option2
}
---
from a performance point of view, is there anything that'd make me
chose one of the options over the other?
i'm assuming option 1 would perform better. is that assumption
correct?

The C Standard specifies nothing about the efficiency of the output of
a piece of compiled C code. It's the purview of the compiler to
optimise the object code. This involves a lot of trade-offs and is
likely to be specific for a compiler and a machine, and a set of
compiler options.

I would not worry about such micro-optimisations. Clarity of code is
much more important. The program can, and should, be profiled for
speed bottlenecks and then corrective action can be taken from a
variety of angles. One such corrective action might involve using
memcpy for copying large structures, but it's something to be decided
on a case-by-case basis and no generalisations are possible.
thanks to all for the inputs. they were quite helpful.
thanks for your time.

Mar 10 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.