Hi all, I'm currently investigating a performance problem which is causing complex objects in Second Life containing many scripts to take a long time to load.
We embed Mono in the Second Life simulator, so I turned on the profiler before initialising the runtime: mono_profiler_load("default:stat"); mono_jit_init("root domain"); mono_internal_call_init(); After shutting down the simulator, the profiler reported the slow method as being System.Reflection.Assembly::Load(byte[]), with each call taking 19.961ms: Time(ms) Count P/call(ms) Method name ######################## 4052.135 203 19.961 System.Reflection.Assembly::Load(byte[]) Callers (with count) that contribute at least for 1%: 102 50 % LindenLab.SecondLife.Script::.ctor(string,byte[],long&) 101 49 % LindenLab.SecondLife.Script::Deserialize(byte[],byte[]) Does this seem right? We're just passing an assembly as bytes to Mono and asking it to turn it in to an assembly, 19ms seems like a long time to do that. Are there any faster ways we could do this? In the example above an object with 200 scripts in it is taking 4s to load, which is much faster than with an LSL script. I get similar results using mono 1.2.6 (which we have embedded in Second Life) or revision 146428, which is pretty close to the tip of svn. Also, the profiler seems to output it's results the first time we unload a domain, is there a way to stop that happening, so we get the full output on shut down? (How should we be creating and destroying appdomains from unmanaged code: we're currently using ves_icall_System_AppDomain_InternalUnload from unmanaged code to unload domains, which is less than ideal...) Cheers, Jim
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list