[Mono-devel-list] [PATCH] String speedup

[Ben Maurer]

Hey,

On Mon, 2004-02-23 at 07:14, Paolo Molaro wrote:
> So this InternalStrcpy change should not be committed: please implement
> it in managed code and report with some meaningful numbers how it
> performs that way.

Ok, so I tried playing around with this a little bit.

The first thing I did was to do a managed memcpy/memmove impl. I used it
for the InternalStrcpy icalls we have right now. To benchmark it, I ran
the following test:


> 		for (int n = 2; n < 50; n += 3) {
> 			string s2 = new String ('a', n);
> 			StringBuilder sb = new StringBuilder (n * 5);
> 			
> 			int t1 = Environment.TickCount;
> 			
> 			for (int i = 0; i < iter; i ++) {
> 				sb.Append (s2).Append (s2).Append (s2).Append (s2).Append (s2);
> 				sb.Length = 0;
> 			}
> 			
> 			int t2 = Environment.TickCount;
> 			
> 			Console.WriteLine (formatString, n,  (t2 - t1) / 1000.0);
> 		}

This tests the speed of copying strings of various lengths. On my box, the results were:
Length + Before ---+ After ---+
   2   |   .388 s  |   .273 s |
   5   |   .426 s  |   .436 s |
   8   |   .419 s  |   .421 s |
  11   |   .440 s  |   .504 s |
  14   |   .462 s  |   .448 s |
  17   |   .480 s  |   .531 s |
  20   |   .468 s  |   .509 s |
  23   |   .490 s  |   .618 s |
  26   |   .495 s  |   .574 s |
  29   |   .499 s  |   .673 s |
  32   |   .493 s  |   .629 s |
  35   |   .516 s  |   .757 s |
  38   |   .507 s  |   .715 s |
  41   |   .524 s  |   .813 s |
  44   |   .531 s  |   .768 s |
  47   |   .536 s  |   .937 s |
-------+-----------+----------+

My implementation of memcpy/memove is attached, with a little test driver.

So, it looks like right now, after len 2 strings, the cost of the icall
becomes lower than the benefit of memcpy.

One other thought I had was somehow using the CPBLK instruction. We
could make method that was transformed into CPBLK by the jit. This way,
we just have to optimize that opcode. Note, that Mono runs the CPBLK
bench mark 3x slower than MS does, so we may have to do some work. Also,
it seems that CPBLK has memcpy type side effects, so we would need to
make a MVBLK varient.

-- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: memcpy.cs
Type: text/x-csharp
Size: 2280 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040223/828ddf66/attachment.bin