[Mono-list] mcs compiles on linux. Now what?

[Paolo Molaro]

On 03/08/02 Martin Baulig wrote:
> > 21 % is spent in Array.Copy. One third of this time is spent in the
> > IsValueType checks. Here we can use the fast copy method even for
> > objects, not only for valuetypes, so that check should not be there, I
> > think: we could have a new icall the do the check or we could integrate
> > the chek in FastCopy (but making it return an error code that is checked
> > and throws an exception or falls back to the slow implementation in C#
> > code).
> 
> So, maybe it was a bad idea to do all the Array.Copy checks in C# -
> especially if IsValueType shows up in the profile at all ?

My point is that the IsValueType check should not be there.
First, if you really want to keep it, one is enough:

	typea.IsValueType && typeb.IsValueType && typea == typeb

is true in all the cases that:

	typea.IsValueType && typea == typeb

is true. This just cut the IsValueType overhead in half.
Second, the current implementation uses the slow setvalue(getvalue)
stuff like the old code did for objects. Arrays of objects can always
use FastCopy if the element type of one array is assign compatible
with the destination array element type. Do you have test where this
would not work?

Third, in the current implementation calling Copy(source, dest, length),
the "(source == null || dest == null)" check is done _three_ times
when one is enough.

> In my do-everything-in-an-icall implementation, the IsValueType was a
> simple integer comparision in C, for instance.
> 
> I'd also suggest doing the "slow implementation" in the interncall -
> especially if you run mcs in the interpreter, a C# function call does
> matter - and the current implementation does 2 * length of the array
> function calls.

See above, the slow implementation should be used only in rare cases,
there is probably no single case in corlib that would involve it: you
are using it for all the object reference copies and that hurts.

> > 20 % of the time is spent in the various StringBuilder.Append (this may
> > explain some of the parsing slowness, I think): we need to speed up that
> > code.
> 
> I can look at this and String.IndexOf next week.

Thanks for your work, martin.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better