[Mono-dev] System.Reflection.Assembly::Load Performance?
vargaz at gmail.com
Tue Dec 1 13:41:22 EST 2009
It is possible that you are using AppDomain.AssemblyLoad which is called
every time an
assembly is loaded ? Or a profiler callback ?
On Tue, Dec 1, 2009 at 7:08 PM, Babbage Linden <babbage at lindenlab.com>wrote:
> Also, there seems to be some caching going on here: I only see the slow
> down the first time I call System.Reflection.Assembly::Load with a given set
> of bytes. Subsequent calls with the same bytes being loaded in to the same
> domain are much faster.
> Are there any tools I can use to continue profiling from managed code back
> in to the mono runtime?
> 2009/12/1 Babbage Linden <babbage at lindenlab.com>
> 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_jit_init("root domain");
>> After shutting down the simulator, the profiler reported the slow method
>> as being System.Reflection.Assembly::Load(byte), with each call taking
>> 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
>> 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...)
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list