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

Zoltan Varga vargaz at gmail.com
Tue Dec 1 13:16:23 EST 2009


On Tue, Dec 1, 2009 at 6:02 PM, Babbage Linden <babbage at 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.

> 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?
This is a problem with the current built-in profiler, it emits all info when
an appdomain is
unloaded, since the methods etc. it collected info about could be going

> (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...)
You should call the managed CreateDomain and UnloadDomain methods using
mono_runtime_invoke () or call a managed method in  your code which calls


> Jim
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091201/fc241342/attachment.html 

More information about the Mono-devel-list mailing list