[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
--
-----------------------------------------------------------------
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list
mailing list