Question about array copy performance.

[linuxfedora]

Which one is faster or any other better way to do it.

I have an array of byte with name:
sendBuffer, and i will like to make some thing like that
the value started from index of the array in realDataSent is now copy
to the beginning of the sendBuffer.

I have tried:
Array.Copy(send Buffer,
realDataSent, sendBuffer, 0, sendBuffer.Leng th - realDataSent);
and this one:
byte[] tempBuffer =
(byte[])sendBuffer.Clo ne();
Array.Clear(sen dBuffer, 0,
sendBuffer.Leng th);
Array.Copy(temp Buffer,
realDataSent, sendBuffer, 0, tempBuffer.Leng th - realDataSent);

Which one is faster or any other better way to do it.

Thanks

[Peter Duniho]

On 2007-11-08 19:36:23 -0800, li*********@yah oo.com.hk said:

[...]
realDataSent, sendBuffer, 0, sendBuffer.Leng th - realDataSent);
and this one:
byte[] tempBuffer =
(byte[])sendBuffer.Clo ne();
Array.Clear(sen dBuffer, 0,
sendBuffer.Leng th);
Array.Copy(temp Buffer,
realDataSent, sendBuffer, 0, tempBuffer.Leng th - realDataSent);

Which one is faster or any other better way to do it.

Well, which one is faster when you try each and time it? That should
be your first step in the investigation, rather than asking in a
newsgroup.

That said, I suspect the first option would be faster, assuming
Array.Copy() is smart about dealing with overlapping arrays. There's
no reason it should need to create a temporary copy of the original
data, so it should be faster. The second option, as compared to a
straight copy, is clearly going to be slower, not even counting that
you include a useless call to Array.Clear().

If the implementation of Array.Copy() is brain-dead and always creates
a temporary copy of a source array that overlaps a destination array,
then I would still expect the first version to be faster. But only
because the second version wastes time with the Array.Clear() call.
Take that out, and the two would be equivalent in that case.

But I doubt the implementation of Array.Copy() is brain-dead. In fact,
I'd guess there's a pretty good chance it's been very well optimized.

Regardless, if you really need to care about the performance of this
section of code, you shouldn't be taking the word of anyone replying to
your question in this newsgroup. You should be measuring the actual
time and finding out the answer first-hand for yourself.

Pete

[Mattias Sjögren]

>Which one is faster or any other better way to do it.

You could consider calling Buffer.BlockCop y instead.

Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Peter Duniho]

On 2007-11-09 14:02:09 -0800, Mattias Sjögren
<ma************ ********@mvps.o rgsaid:

>Which one is faster or any other better way to do it.

You could consider calling Buffer.BlockCop y instead.

Why? When an existing data copying method already exists, what
advantage would there be in using Buffer.BlockCop y()? Is it really so
much faster than just calling Array.Copy() to justify sacrificing
readability and type-consistency?

Pete

[Cor Ligthert[MVP]]

Peter,

In my opinion is this often investigated, why don't you do that yourself or
search these newsgroups (it can be that it was in the languages.vb
newsgroup).

(It is partially just joking reflecting your answer to Linuxfedora, what
Mattias wrote is well knowed, I was searched this answer in my mind and
Mattias answer was reminding it to me.)

Cor

[Peter Duniho]

On 2007-11-10 01:24:26 -0800, "Cor Ligthert[MVP]"
<no************ @planet.nlsaid:

In my opinion is this often investigated, why don't you do that
yourself or search these newsgroups (it can be that it was in the
languages.vb newsgroup).

I have. But what happens when my own investigations disagree with
someone's claims? Should I not give them an opportunity to explain
themselves?

(It is partially just joking reflecting your answer to Linuxfedora,
what Mattias wrote is well knowed, I was searched this answer in my
mind and Mattias answer was reminding it to me.)

It appears to me that what "is well knowed [sic]" is frequently wrong.

And it appears to be so in this case as well. I did in fact write some
test code, and there is practically no difference at all between using
Array.Copy() and Buffer.BlockCop y(). In fact, in my tests Array.Copy()
came out slightly faster when copying within an array (and slightly
slower copying from one array to another).

The performance differences were in roughly the same ballpark as those
that exist simply because of the multi-tasking environment (i.e. the
resulting times for each test varied nearly as much from one execution
of a test to the next, as they do between the specific alternative
algorithms being tested). The largest difference I was able to
reproduce was a mere 5%, hardly consequential even if _all_ that the
code does is copy arrays, and a completely trivial difference for any
code that does anything else that's at all interesting.

It's frustrating to me to see so many people just blindy repeat
"convention al wisdom", things that they have "researched " (as you have
here) only by searching other posts in the newsgroups. As some wise
people in my life have always told me, "believe nothing you read, and
only half of what you see". A bit hyperbolic, but there's a very large
grain of truth in that statement.

So, the question still stands: does anyone have any _concrete_,
firsthand information that would suggest that using Buffer.BlockCop y()
in this situation is in fact a superior choice, considering the
tradeoffs involved?

Pete

[Mattias Sjögren]

>Why? When an existing data copying method already exists, what

>advantage would there be in using Buffer.BlockCop y()? Is it really so
much faster than just calling Array.Copy() to justify sacrificing
readability and type-consistency?

I'm just saying he should know what options are available. I'll leave
the benchmarking and decision of which method to use to the original
poster.

I don't see why calling Buffer.BlockCop y rather than Array.Copy would
sacrifice readability.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Peter Duniho]

On 2007-11-11 13:18:00 -0800, Mattias Sjögren
<ma************ ********@mvps.o rgsaid:

I'm just saying he should know what options are available. I'll leave
the benchmarking and decision of which method to use to the original
poster.

You didn't say it was simply an alternative. You said it should be
used instead. That's not leaving "the decision of which method to use
to the original poster". You made a specific recommendation. I asked
why you did.

I don't see why calling Buffer.BlockCop y rather than Array.Copy would
sacrifice readability.

Well, for one, Buffer.BlockCop y() is byte-based, not element based,
which means that using it on arrays that aren't arrays of bytes has to
include code to convert numbers of elements to numbers of bytes.

IMHO, there are other issues as well. The fact that you're dealing
with an array means that methods on the Array class are more suitable
generally, at least from a readability point of view (especially if you
can use an instance method, which is often the case). It's a simple
matter of whether you have to go outside the class you're using or not.
IMHO, it's always more readable to stick with the class you're using,
than to use some helper class.

That's not to say helper classes don't have their place. But when
using one, it should be for a good reason.

Pete

[Mattias Sjögren]

>You didn't say it was simply an alternative. You said it should be
used instead. That's not leaving "the decision of which method to use
to the original poster". You made a specific recommendation. I asked
why you did.

Ok, maybe I could have phrased that better. You'll have to excuse my
English, it's far from perfect since it's not my native language. But
to me there's a significant difference between "could consider" and
"should be used".

>Well, for one, Buffer.BlockCop y() is byte-based, not element based,
which means that using it on arrays that aren't arrays of bytes has to
include code to convert numbers of elements to numbers of bytes.

The OP was working with byte[] so in this case that's a non-issue.

>IMHO, there are other issues as well. The fact that you're dealing
with an array means that methods on the Array class are more suitable
generally

Right, but I'm not talking about the general case. The OP specifically
asked for alternatives and that's what I replied to (ok, "any other
better way to do it", and I didn't mean to imply that Buffer.BlockCop y
is necessarily better) .

Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.