I think that some confusion stems from the fact that it's a difference between
referencing the assembly, and dynamically instancing classes out of it.
If you reference classes directly, as in
mything = new Thing();
where thing could be a module, albeit _referenced_, not _loaded_
is a huge difference to
mything = loadedAssembly.Instantiate( "Thing" );
in the former, the jit compiler can do all kinds of neat optimizations when
referencing classes in the Assembly, since it has both the referenced component
and the referrer at hand. It can also inline and optimize away type validity
checks and trusted domain checks.
In the latter, it really can't, and need to wrap everything in prudent
encapsulation, protection and indirection.
Optimization points aside, I would hate for us to expand the core modules into
separate projects just because we can; I think we would have to add 20 more
projects to the solution and that would just suck - especially now that we have
cleaned out so many. Some of the these new projects will have just a handful of
classes, which is just an absurd waste of resources for something that should
be used in 95% of the setups.
I actually don't know how mono addins work, but in the .net framework
individual classes are referenced by assembly and class if loaded at runtime,
so for examble
authModule= "MyAuthLib.dll, MyAuthenticator" would reference the class
MyAuthenticator in the dll MyAuthLib.dll - which means that you can lump as
many of those together in an dll that you want to.
so we should make sure we can do something liket that, and instead try to lump
modules that share a common domain together.
The only two reasons to ever split an assembly into two is from
* references being too different (if you want to re-use them separately)
* encapsulation and security issues (actuallly USING internal as it was
intended)
So, what I'm saying is that we should strive towards a situation where the core
modules are bundled into a minimal set of assemblies, and the rest put on forge.
Best regards,Stefan AnderssonTribal Media AB
> Date: Thu, 29 Jan 2009 11:28:19 +0100> From: drscofi...@xyzzyxyzzy.net> To:
> opensim-dev@lists.berlios.de> Subject: Re: [Opensim-dev] proposal: cleanup
> and break up region modules> > Tleiades Lauridsen wrote:> > > > > >> Date:
> Thu, 29 Jan 2009 08:31:48 +0100> >> From: drscofi...@xyzzyxyzzy.net> >> To:
> opensim-dev@lists.berlios.de> >> Subject: Re: [Opensim-dev] proposal: cleanup
> and break up region modules> >>> >> Tleiades wrote:> >> >> I'd be much more
> of a fan of having each module a seperate dll. Files> >> >> are cheap too. :)
> And that makes it very clear to people what they are> >> >> loading, and what
> they aren't loading.> >> >>> >> >> >> > (On the fear of talking about
> performance prematurely)> >> > Won't that cause problems for the JIT'er?> >>
> >> >> > Normally access to member variables gets optimized away into a
> direct> >> > memory access rather than invocation of a JSR. If I recall
> correctly> >> > this optimization does not work for dynamically loaded
> assemblies.> >>> >> well, if that's the case, then it's not working currently
> either :-)> > currently> >> we lump all region modules into one large super
> DLL and load that> > dynamically.> > > > I guess what I'm saying is that dll
> files are not as cheap as it is> > being implied. Having an application
> dynamicallly load a large number of> > dll's at runtime, is less efficient
> that loading a few large dll's> > during load time. The JIT'ed code will be
> less efficient and loadtime of> > the application will increase. While load
> time may not be a big issue, I> > believe it is best to give the JIT engine
> the best working condition.> > we are always loading at runtime --- or let me
> ask the other way round: what do> you define as "loadtime"?> > > > > > As I
> understand it the JIT engine and assembly loader have been designed> > based
> on a use pattern which states: "Most assemblies will be loaded> > during
> application load time, and only few assemblies will be loaded at> > a latter
> stage",> > well, we are loading at runtime then.> > -- > dr dirk husemann
> ---- virtual worlds research ---- ibm zurich research lab> SL: dr scofield
> ---- drscofi...@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/> RL:
> h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/>
> _______________________________________________> Opensim-dev mailing list>
> Opensim-dev@lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
