Regarding xml serialization performance, you should take into account that MS.NET and Mono have an important difference. The first time you try to serialize or deserialize a type, MS.NET generates and compiles an add-hoc serializer for the required types on the fly. Mono on the other hand, only generates the add-hoc serializer after a given number serializations (this threshold can be set using the MONO_XMLSERIALIZER_THS env var).
In your test case MS.NET will be better because you are deserializing a lot of data and the overhead of generating the add-hoc serializer, even for a single deserialization, is worth it. Mono will be worse in this case, but will be better in other cases. You can try setting MONO_XMLSERIALIZER_THS=0 to make Mono behave like MS.NET. Lluis. El dj 10 de 01 del 2008 a les 19:11 +0000, en/na Alan McGovern va escriure: > Ok, here's an updated patch which caches the method for reuse as long > as both the list type and listitemtype are the same as the previous > invocation. > > This gives a modest 13% increase in performance for the testcase i was > using. Let me know if this is good to commit as-is. > > Just as a point of style, should i put the variable declarations at > the top of the .cs file with a comment specifying how they are used? > Or should i leave them as they are. > > Alan. > > On Jan 10, 2008 3:26 AM, Alan McGovern <[EMAIL PROTECTED]> wrote: > > (and to the list again... doh) > > > > > > On Jan 10, 2008 3:26 AM, Alan McGovern <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > Yeah, by reducing the method searchs performance increases by 15% or > > > so. I'll work that patch up tomorrow at some stage. > > > > > > Thanks, > > > Alan. > > > > > > > > > On Jan 10, 2008 1:07 AM, Robert Jordan <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > I've filed it: > > > > > > > > https://bugzilla.novell.com/show_bug.cgi?id=352805 > > > > > > > > BTW, the "previousObject" check in your patch is still useful, > > > > as it cuts down the type.GetMethod ("Add") calls from > > > > collectionLength to 1, if I understand the patch correctly. > > > > > > > > Just remove the CreateDelegate stuff and extend the optimization > > > > to cover NET 1.1 as well. > > > > > > > > Robert > > > > > > > > > > > > > > > > Alan McGovern wrote: > > > > > (and also sending to the list...) > > > > > > > > > > On Jan 10, 2008 12:41 AM, Alan McGovern <[EMAIL PROTECTED]> wrote: > > > > >> Hi, > > > > >> > > > > >> I was wondering about that alright. It did seem a bit weird that it > > > > >> would work, i would've expected the delegate parameter to be at least > > > > >> as restrictive as the method i was calling. Bang goes that idea then. > > > > >> > > > > >> Alan. > > > > >> > > > > >> > > > > >> On Jan 10, 2008 12:36 AM, Robert Jordan <[EMAIL PROTECTED]> wrote: > > > > >>> Robert Jordan wrote: > > > > >>>> Alan McGovern wrote: > > > > >>>>> There was a thread a week or two ago called 'Speed difference > > > > >>>>> Windows > > > > >>>>> - Linux' which noted there was a big difference in performance > > > > >>>>> between > > > > >>>>> .NET and mono. I did a brief bit of profiling and came up with > > > > >>>>> this > > > > >>>>> patch which improves performance ~30% for the testcase which was > > > > >>>>> attached in the email. This reduces runtime memory usage by about > > > > >>>>> 10MB > > > > >>>>> (80MB -> 70MB) and decreases processing time by 30% (3.4s -> > > > > >>>>> 2.6s). > > > > >>>>> > > > > >>>>> Anyone have any ideas on how to tidy this up to make it neater? > > > > >>>>> Also, > > > > >>>>> would this optimisation be too specific, or can it be generalised > > > > >>>>> somewhere higher up in the stack. > > > > >>>> I don't think the patch is correct. It is assuming that every > > > > >>>> "Add" method of a collection/list is compatible with > > > > >>>> AddDelegate(object). > > > > >>>> > > > > >>>> If the test cases are still working, it could be that > > > > >>>> CreateDelegate is buggy: MSDN states: > > > > >>>> > > > > >>>> "A parameter of a delegate is compatible with the corresponding > > > > >>>> parameter of a method if the type of the delegate parameter is more > > > > >>>> restrictive than the type of the method parameter, because this > > > > >>>> guarantees that an argument passed to the delegate can be passed > > > > >>>> safely > > > > >>>> to the method." > > > > >>> It's indeed a bug in Mono's CreateDelegate. The following test case > > > > >>> must fail but it doesn't: > > > > >>> > > > > >>> using System; > > > > >>> > > > > >>> delegate void Method(object o); > > > > >>> > > > > >>> class T > > > > >>> { > > > > >>> static void Main () > > > > >>> { > > > > >>> T t = new T (); > > > > >>> Method m = (Method) Delegate.CreateDelegate > > > > >>> (typeof(Method), t, > > > > >>> t.GetType ().GetMethod ("Test")); > > > > >>> m (new Uri ("http://mono-project.com";)); > > > > >>> } > > > > >>> > > > > >>> public void Test (Uri uri) > > > > >>> { > > > > >>> Console.WriteLine (uri); > > > > >>> > > > > >>> } > > > > >>> } > > > > >>> > > > > >>> Robert > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Mono-list maillist - [email protected] > > > > >>> http://lists.ximian.com/mailman/listinfo/mono-list > > > > >>> > > > > > _______________________________________________ > > > > > Mono-list maillist - [email protected] > > > > > http://lists.ximian.com/mailman/listinfo/mono-list > > > > > > > > > > > > > > > > > > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
