Sander van Rossen wrote:
> Just to play the devils' advocate;
>
> If we do a full program optimalisation phase on each application
> that's installed on the system and include system/corelib we could
> possibly get a speed improvement compared to using them as a seperate
> lib.
>
Very interesting, however, one slight issue with that: if the user
installs a corlib version 1.0.2.1 on top of a 1.0.0.0 everything will
need to be re-optimized.
> All the functionality that's in system/corelib that wouldn't be used,
> wouldn't be included in the binary.
>
> Also, code memory usage will be far less compared to actuall data memory
> anyway.
> (but then again, executables contain a lot of resources in the form of
> images etc. these days)
>
I guess it also saves the JITter from having to recompile a method each
time a new appdomain asks for it. It could also help reduce memory
fragmentation (I am not 100% sure on that opinion though). Let's not
forget the benefit of paging issues.
Resources are not stored in memory, until they are needed. They are read
from disk the first time round (This was an issue in our company and I
did some profiling to test it). So I guess the code stays small.
> Another thing to consider is that we might, eventually, want to be
> able to let applications use different versions of the
> system/corelib..
>
Then you will need two versions in memory, but you wouldn't have an
instance of the JITted code for each application, only for each library.
The JITter works almost exactly the same, only it only ever compiles
code once (unless the system is rebooted or the code is no longer needed).
We could also do some mean code memory protection with this method of
doing things.
> On Dec 25, 2007 10:21 PM, Jonathan Chayce Dickinson
> <[EMAIL PROTECTED]> wrote:
>
>> [...]
>>
--
Jonathan Dickinson
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
