---- Reported by marek.safar@seznam.cz 2007-01-17 19:21:30 MST ----

Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

I have made some performance testing after latest updates
in this array and performance was definitely improved.
However, it looks like we are still missing some GC tricks
which can still speed up the process .


Steps to reproduce the problem:
1. mini benchmark

using System;

class T
{
	static void Test ()
	{
		long [] a1 = new long [6] { 0, 1, 2, 3, 4, 5	};	
	}
	
	public static void Main ()
	{
		DateTime s = DateTime.Now;
		for (int i=0; i < 10000000; ++i)
			Test ();
		
		Console.WriteLine (DateTime.Now - s);
	}
}

Actual Results:

Compiler  Runtime  Time
MCS       MS       03.7187500
MCS       Mono     02.5150000
CSC       MS       00.6718750
CSC       Mono     02.5780000

What is interesting on the figures is that CSC+MS pair
is 4x faster than MCS+Mono pair. But same program compiled
by MCS does get that boost on MS runtime.

There is almost no IL difference between program compiled
by MCS and CSC except that CSC produces static initializer
with name decorated with size of array.

But I am not sure whether they can trigger some GC optimization
based on a class name or I am missing some other trick.

Expected Results:

Better performance.

How often does this happen? 


Additional Information:



---- Additional Comments From lupus@ximian.com 2007-01-18 07:15:14 MST ----

Closing as duplicate as far as mono is concerned.
The surprising result is that the MS runtime is so much slower
with the mcs-compiled binary. One issue here may be that mcs
is buggy and will add 4 bytes to the rva data: the size difference may
cause the MS jit to deoptimize.
I also suggest that mcs decorate the type name with the size and reuse
the same type for same sized arrays of data (this allows creating less
types and accessing less metadata at runtime: note use a size in
bytes, not elements).
The benchmark is also buggy, because it doesn't use the array, so the
runtime could completely remove the allocation.

*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO78016 ***



---- Additional Comments From marek.safar@seznam.cz 2007-01-18 09:36:09 MST ----

FYI, I found what causes the slowdown.

MS made that optimization as part of .NET 2.0 because
when I recompiled same program with gmcs to use 2.0
corlib the result were as expected (same speed on MS
runtime).


Unknown operating system unknown. Setting to default OS "Other".
This bug was marked DUPLICATE in the database it was moved from.
    Changing resolution to "MOVED"