[Mono-dev] cecil optimization design proposal

[Jb Evain]

Hey Roei,

I've received the first mail.

Reviewing the patch is in my stack of things to do this week. But I'm
also in the middle of my move, so I'll complete my review probably
only next week.

Jb

On 9/5/07, Roei Erez <roeie at mainsoft.com> wrote:
>
>
>
>
> Hi all,
>
> I am sending this mail again, because the last one was sent without a
> subject, so ignore it if you have already read it.
>
>
>
> As a continue to the last discussion of cecil memory consumption, I am
> attaching some changes that emphasize the concepts.
>
> In order to remind everyone and to introduce the problem to the 'mono-cecil'
> group here is a summary:
>
>
>
> We have noticed that cecil consume relatively a lot of memory.
>
> This is due to the fact the code builds a full object model on top of the
> assembly basic tables.
>
> Many users are only interested in reading a part of the assembly; therefore
> the full object model is sometimes redundant.
>
>
>
> At the last discussion we were considering some options:
>
> 1.       Get rid of the basic tables after building the object model.
>
> 2.       Make the object model lazy, where the objects are accessing the
> basic tables directly.
>
> 3.       Maybe expose a way to load an assembly in a read-only way, which
> will make the implementation easier.
>
>
>
> I have made some thinking (and coding) regarding the second option, which I
> think is the right way to do it, and you can look at the attached diff as a
> proposed design.
>
> Here are some explanations about the code changes:
>
>
>
> A new class 'LazyReflectionReader' is introduced, which is responsible for
> the lazy assembly reading. This class does not build all the TypeDefinition,
> MethodDefinition, FieldDefinition … objects at the beginning, but only when
> they are accessed. It also provide some internal helper methods for
> resolving the relations between elements, for example
> 'GetDeclaringType(MetadataToken token)', which is used by the lazy 'object
> model' classes. Currently not all fetching is lazy, but you still can see
> the differences in terms of load time and memory consumption.
> The object model instances that are instantiated by the
> 'LazyReflectionReader' are not populated with their entire dependencies for
> example TypeDefinition is not populated with its Methods, instead they are
> calling the helper methods in the 'LazyReflectionReader' in order to resolve
> the dependencies on request.
> A new class 'MetadataRelations' is introduced which is used as a
> preprocessor of the assembly, and creates the relations to be used by the
> helper methods.
> I have added a method on AssemblyFactory class: 'GetAssembly (string file,
> bool lazy)'.This method loads an assembly in a lazy way, and I have added
> this method only for the purpose of playing with the two implementations and
> see the differences, it is not part of the design.
>
>
>
> Here are some design issues that I have encountered during my work:
>
> 1. Remove the sealed modifier from the object model classes (
> TypeDefinition, FieldDefinition, MethodDefinition…   ) so we can derive from
> them?
>
> 2. Exposing a way to plugin you own ReflectionReader, so the use can
> implement his own object model loading?
>
>
>
> This code is not tested, and is provided for design purpose. Nevertheless
> you are welcome to measure the differences in loading time and memory
> consumption between the lazy and not lazy load.
>
> Any comments, remarks are very welcome.
>
>
>
> Regares,
>
> Roei Erez
>
>
>


-- 
Jb Evain  <jb at nurv.fr>