Question about array copy performance.

  • Thread starter Thread starter linuxfedora
  • Start date Start date
L

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(sendBuffer,
realDataSent, sendBuffer, 0, sendBuffer.Length - realDataSent);
and this one:
byte[] tempBuffer =
(byte[])sendBuffer.Clone();
Array.Clear(sendBuffer, 0,
sendBuffer.Length);
Array.Copy(tempBuffer,
realDataSent, sendBuffer, 0, tempBuffer.Length - realDataSent);

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

Thanks
 
[...]
realDataSent, sendBuffer, 0, sendBuffer.Length - realDataSent);
and this one:
byte[] tempBuffer =
(byte[])sendBuffer.Clone();
Array.Clear(sendBuffer, 0,
sendBuffer.Length);
Array.Copy(tempBuffer,
realDataSent, sendBuffer, 0, tempBuffer.Length - realDataSent);

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

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
 
Which one is faster or any other better way to do it.

You could consider calling Buffer.BlockCopy instead.



Mattias
 
You could consider calling Buffer.BlockCopy instead.
Click to expand...

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

Pete
 
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
 
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).
Click to expand...

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.)
Click to expand...

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.BlockCopy(). 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
"conventional 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.BlockCopy()
in this situation is in fact a superior choice, considering the
tradeoffs involved?

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

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.BlockCopy rather than Array.Copy would
sacrifice readability.


Mattias
 
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.
Click to expand...

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.BlockCopy rather than Array.Copy would
sacrifice readability.
Click to expand...

Well, for one, Buffer.BlockCopy() 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
 
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.
Click to expand...

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.BlockCopy() 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.
Click to expand...

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
Click to expand...

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.BlockCopy
is necessarily better) .



Mattias
 
Back
Top