2009/12/1 Zoltan Varga <var...@gmail.com> > On Tue, Dec 1, 2009 at 6:02 PM, Babbage Linden <babb...@lindenlab.com>wrote: > >> 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 can't reproduce this, most of the work happens in native code, could you > try running under > valgrind --tool=callgrind, that will profile the runtime code. >
OK, I have a (15MB) callgrind.out file, what's the best way for me to get it to you? Cheers, Jim
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list