[Mono-dev] embedded runtime questions

[Allan Hsu]

On Sep 12, 2005, at 6:08 AM, Paolo Molaro wrote:

> Upgrade to 1.1.9, this issue should be fixed (at least as long as you
> call mono_thread_attach()).

I've noticed that there is a matching function called  
mono_thread_detach(). Do I need to call this before the thread exits?

>> <junk about using mono_thread_create>
>
> It's not fine as the thread stack is not registered with the GC so  
> some
> objects could be freed under your back. Upgrading to 1.1.9 should not
> require this hack.

Good to know. I will stop doing this:)

> Some of the complexity is because that function is also very flexible.
> We may provide an API like the following:
>     typedef void* MonoInvokeHandle;
>
>     MonoInvokeHandle mono_runtime_prepare_invoke (MonoMethod *method);
>     MonoObject*      mono_runtime_invoke_handle  (void *obj, void  
> **params, MonoObject **exc, MonoInvokeHandle method_handle);
>
> You can easily prototype that, and test to see how much of a  
> speedup it is.
> My plan is to eventually do it with a different invoke interface,
> though, because in my tests the biggest overhead with the current
> interface is that we need to allocate an object if the method  
> returns a
> valuetype: I'd like to fix both performance issues at once.

I'll give this a try. I'll report back here with my findings. Is  
there a timeline for when you want to get this sort of functionality  
into Mono?

>> Full, non-cached embedded Mono C API lookup/invocation (parent
>> lookup, etc): ~6 usec
>> locally saved Mono C API (using the same MonoMethod* over and over):
>> ~2.9 usec
>> self-written caching, using Judy Arrays: ~3.2 usec
>>
>> I'm currently using a caching scheme that uses (MonoClass*, method
>> name, number of arguments) as a key that maps to MonoMethod*
>>
>
> The lookup is going to be your bottleneck with the above interface:
> why do you need to poerform it at every call?

This type of method calling is intended for a general use case where  
the convenience of not requiring the caller to keep track of a  
MonoMethod* outweighs the ~10% performance penalty incurred from  
caching/lookup (and 10% is a whole lot better than our previous 100%  
when we weren't caching at all :) It doesn't prevent the caller from  
using the faster form, but that doesn't mean it shouldn't be decently  
fast.

-Allan

--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779