hmm this would be a possibility to look at. but would require us to rewrite all of our code to no longer use cecil objects directly. This is the longer term plan. We would prefer something a bit less involved (lower risk) at this time.
One question, I assume when you use 14 mb of memory that is only for your model (not including the memory cecil uses when loading up of this model as it will be more from what we have seen, it loads up bunches of byte arrays to hold assembly data in the large object heap). On Wed, Sep 14, 2011 at 5:07 AM, Daniel Grunwald <[email protected]> wrote: > Which metadata do you need exactly? > > ICSharpCode.NRefactory.TypeSystem provides a view on the types and > members in an assembly, and can be initialized using CecilLoader. > When loading the public types/members (using > CecilLoader.IncludeInternalMembers=false, which is the default) from the > following assemblies (the default references is a new WPF project): > - mscorlib > - System > - System.Core > - System.Data > - System.Data.DataSetExtensions > - System.Xml > - System.Xml.Linq > - PresentationCore > - PresentationFramework > - WindowsBase > - System.Xaml > > NRefactory 5 takes only 14 MB of memory with all of these loaded (and > when also including internal/private members: 32 MB), and I have some > ideas on how to reduce this even further. > You can also speed up the load time by serializing the type system - > loading this set of assemblies and copying the info from Cecil to > NR.TypeSystem takes 2 seconds, but deserializing a cached copy of the > type system using NR's FastSerializer takes only 0.25 seconds. > > The downside is that you don't get all the information from an assembly > - e.g. it's missing the method bodies. But pretty much everything else > is present - types, methods, fields, properties, events, parameters, > custom and non-custom attributes, security declarations, constant > values, etc. > > You can find NRefactory on https://github.com/icsharpcode/NRefactory/ > > Daniel > > On 9/14/2011 01:40, Greg Young wrote: >> To be clear, I can patch to not use the LOH pretty quickly and easily >> its the everything gets held in memory part thats a bit of an issue we >> really only need the metadata and it seems that getting the metadata >> copied over will be a pretty involved task. >> >> On Tue, Sep 13, 2011 at 7:37 PM, Greg Young <[email protected]> wrote: >>> I know I have put up some discussion about this in the past but is >>> there anyway (possibly something new) to lower cecil's memory usage? >>> >>> I have looked at copying over cecil objects and it would be a pretty >>> major task. The alternative is to make cecil objects as short lived as >>> possible. Basically what we want is to only hold all of the metadata >>> that is provided and none of the code. We have already taken the easy >>> mechanism of setting MethodBodys to a new MethodBody after reading >>> them but the module still holds the whole assembly in the LOH. >>> >>> Greg >>> >>> -- >>> Le doute n'est pas une condition agréable, mais la certitude est absurde. >>> >>> -- >>> -- >>> mono-cecil >> >> > > > -- Le doute n'est pas une condition agréable, mais la certitude est absurde. -- -- mono-cecil
