[Mono-dev] embedded runtime questions
allan at counterpop.net
Mon Sep 12 15:47:05 EDT 2005
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
> 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
>> 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
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779
More information about the Mono-devel-list