[Mono-dev] System.Reflection.Assembly::Load Performance?

[Babbage Linden]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091201/8f6f6d45/attachment.html