Faster byte[] copy #511
Faster byte[] copy #511
Conversation
| @@ -5,6 +5,7 @@ | |||
| using System.IO; | |||
| using System.Threading; | |||
| using System.Threading.Tasks; | |||
| using IllyriadGames.ByteArrayExtensions; | |||
There was a problem hiding this comment.
VectorizedCopy is in a standalone lib as it has a wide applicable use in many different situations; adding a reference seemed easier than including the source here, or Common and trying to workout what do with the file headers (here and in the standalone lib). Happy to take advice 😀
Hopefully the clr will change so it isn't needed; and everything can get the benefit, but equally that might either be a change to memmove in the C Standard Lib; or will be coreclr only for stability, so I'm not holding my breath on timelines 😦
There was a problem hiding this comment.
Added reference as specific version number; so the code referenced is under nuget's control not mine 😉
Though would probably be "safer" to use the source; but... dotnet/corefx#3199 (diff) don't know what the situation is.
There was a problem hiding this comment.
But you know we're not going to have a dependency on "IllyriadGames.ByteArrayExtensions": "1.0.0-beta-10" in our web server right? 😄
There was a problem hiding this comment.
Doubt it 😄
What about a source file with a different copyright notice; but using same licence (Apache License, Version 2.0)? Not sure you'd be comfortable with the precedent either... Everyone would want a header! 😝
But only adding the Copyright (c) .NET Foundation. header would mean I'd be in the perverse situation of sub-licensing VectorizedCopy and would need to retain the header if I was to use it under Apache 2.0? (as I understand it)
There was a problem hiding this comment.
Want to drop net451 and move to only supporting net46? I've just been made aware of Buffer.MemoryCopy which should offer better performance... (Doesn't appear till 4.6 and coreclr)
Could ifdef it I suppose...
There was a problem hiding this comment.
net46 will likely break Mono. Not necessarily the most recent released version or master, but quite likely the one release that comes most closely to working: 4.0.x.
There was a problem hiding this comment.
We're going to be moving to .NET 4.6 for RC2. We'll need to see how much of mono breaks when we do that. Hopefully 4.2.x will have enough 4.6 support to run.
There was a problem hiding this comment.
(sorry for continuing here)
Switching to .NET 4.6 will break current Mono users. The switch to the .NET 4.6 reference source only happened back in October, so all versions of Mono (including the most recent 4.2 and the mostly-working 4.0) don't have the Array.Empty member. Things will go back the way they were in beta2: aspnet/dnx#1105
There was a problem hiding this comment.
Yep, this is known. I'm working with the mono guys to figure out which version of mono will support .NET 4.6 reference assemblies. Hopefully by the time RC2 is ready we'll have a version of mono that supports that.
|
Closed as still investigating |
|
@benaadams Any updates on this. I think it is still possible to make it faster than |
|
Holding off till post v1.0.0 RTM |
This makes me sad that this is even possible to do (+4% RPS)...
Issue: "Array.Copy & Buffer.BlockCopy x2 to x3 slower < 1kB" https://github.com/dotnet/coreclr/issues/2430
Until that is fixed, there is this, +4% RPS
Before
After