[Mono-devel-list] Embedding Mono in a Virtual World

Paolo Molaro lupus at ximian.com
Wed Jan 26 12:25:41 EST 2005

On 01/26/05 Jim Purbrick wrote:
>  --- Paolo Molaro <lupus at ximian.com> wrote: 
> > If the same scripts are run multiple times I'd
> > expect a large performance improvement.
> The scripts are event based and most of the time spent
> executing scripts will be repeatedly calling the event
> handlers of running scripts. Presumably each handler
> will be JIT compiled the first time it's run and then
> be running native code in subsequent calls.

Yep, sounds good.

> It will be important to unload scripts and JIT output
> for scripts when they are no longer referenced so
> there isn't a build up of compiled and JITed code
> which will never be run again.

Mono has implemented the DynamicMethod feature that helps with this:
you create a method at runtime using Reflection.Emit and
you get back a delegate: once the delegate will be garbage
collected, the native code will be reclaimed, too.

> > So it very much depends on what is the behaviour of
> > the scripts: you might want to have your system use 
> > the threadpool. [...] This works if the scripts are
> > supposed to be short-lived.
> Script lifetime is normally tied to the life cycle of
> the object it is attached to.

With short-lived I meant the time taken to execute the
script, not how long the script will be kept around.

> With the current interpretted system, event handlers
> are called by the system and run until they exit or a
> quanta has elapsed and then another script is
> scheduled. Would a similar approach be possible using
> Mono? Would it be a good way to go?

You can run the scripts in a thread and abort or
interrupt the thread after a timeout, but that won't
save the state of the script if you meant to reload
it later and restart it from where it was interrupted.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list