Fix threshold for PInvoke path in Buffer.Memmove

Threshold for PInvoke path in Buffer.Memmove was way too low. I suspect it was tuned based on the debug builds. I have updated it to be
at the lower end of the break-even point range, based on measurements on several different types of hardware. The best improvements are
on i7-3520M: 64-byte aligned memory blocks - 35% faster, 128 byte aligned memory blocks - 17% faster.

Also:
- Delete misleading comment about PInvoke overhead
- Add comment related to #430

1 files changed, 5 insertions, 3 deletions

diff --git a/src/System.Private.CoreLib/src/System/Buffer.cs b/src/System.Private.CoreLib/src/System/Buffer.cs
index 810fc6d89..5fad5f70b 100644
--- a/src/System.Private.CoreLib/src/System/Buffer.cs
+++ b/src/System.Private.CoreLib/src/System/Buffer.cs
@@ -261,6 +261,9 @@ namespace System
             // This is portable version of memcpy. It mirrors what the hand optimized assembly versions of memcpy typically do.
             //
 
+#if ALIGN_ACCESS
+#error Needs porting for ALIGN_ACCESS (https://github.com/dotnet/corert/issues/430)
+#else // ALIGN_ACCESS
             switch (len)
             {
                 case 0:
@@ -383,9 +386,7 @@ namespace System
             }
 
             // P/Invoke into the native version for large lengths.
-            // On desktop, we only PInvoke for lengths >= 512. Since the overhead of a PInvoke is cheaper here,
-            // we are able to PInvoke for smaller copy workloads (length >= 50) and still get a benefit.
-            if (len >= 50)
+            if (len >= 200)
             {
                 _Memmove(dest, src, len);
                 return;
@@ -461,6 +462,7 @@ namespace System
             }
             if ((len & 1) != 0)
                 *dest = *src;
+#endif // ALIGN_ACCESS
         }
 
         // Non-inlinable wrapper around the QCall that avoids poluting the fast path