<HTML dir=rtl><HEAD><TITLE>Re: [Mono-dev] Cecil improvement</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD>
<BODY dir=ltr>
<DIV dir=ltr align=left><FONT face=Arial color=#000000 size=2>&gt; And how do you plan to represent those relations?</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2>We need to represent two types of relations:.</FONT></DIV>
<OL dir=ltr>
<LI>
<DIV align=left><FONT face=Arial size=2>one to one (like Fields -&gt; FieldLayout)- can be implemented as an unsinged int array, where for each element the index represents the&nbsp;&nbsp; RID of the source and the value represents the RID of the target.</FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Arial size=2>one to many(like Method -&gt; CustomAttributes) - same concept but with two dimensions array.</FONT></DIV></LI></OL>
<DIV dir=ltr align=left><FONT face=Arial size=2>Of course we need to wrap it and define a good interface for such a relation.</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2>I have already tries&nbsp; working with such a relation implementation, and it looks good in terms of memory consumption.</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2>&gt; I'll create a branch for Cecil so we can experiment.</FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2>That will be great, let me know when you do that.</FONT></DIV>
<DIV dir=ltr align=left><FONT size=2></FONT><BR>Regards, </DIV>
<DIV dir=ltr align=left>Roei Erez</DIV>
<DIV dir=rtl>
<HR tabIndex=-1>
</DIV>
<DIV dir=rtl><FONT face=Tahoma size=2><B>מאת:</B> Jb Evain [mailto:jb@nurv.fr]<BR><B>נשלח:</B> ד 22/08/2007 04:53<BR><B>אל:</B> Roei Erez<BR><B>עותק לידיעה:</B> mono-devel-list@lists.ximian.com<BR><B>נושא:</B> Re: [Mono-dev] Cecil improvement<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Hey,<BR><BR>On 8/22/07, Roei Erez &lt;roeie@mainsoft.com&gt; wrote:<BR>&gt; When writing an assembly a user needs to build the full object model, so<BR>&gt; I don't think there is a lot of room for improvement at this area.<BR><BR>Well, it's difficult, but if it's possible to read the object model<BR>from the raw bytes, it should also be possible to write it back.<BR><BR>&gt; I agree that cecil should expose an interface to load an assembly as<BR>&gt; 'Read Only', where the optimizations should be activated, and by that<BR>&gt; save the worrying of the changes to the assembly writing part.<BR>&gt; I really like the idea that the object model will access the raw tables<BR>&gt; directly and in lazy way.<BR>&gt; This idea will work only if the access to the raw table will be fast,<BR>&gt; and in order to do so, the code needs to build more relations between<BR>&gt; these tables.<BR>&gt; We can take the CustomAttributes table for example, each raw at this<BR>&gt; table has the 'RID' of the owner element, and the TokenType of the<BR>&gt; owner, and in order for a 'Field', for example, to load its<BR>&gt; CustomAttibutes lazily, it needs that opposite relation, from its 'RID'<BR>&gt; to its CustomAttributes, will exist.<BR>&gt;<BR>&gt; I basically want to suggest the following:<BR>&gt; The methods of the ReflectionReader will be changed, and instead of<BR>&gt; building an object model, they will only build the desired relations<BR>&gt; between elements (Methods-&gt;Types, Fields-&gt;Constants,<BR>&gt; Fields-&gt;InitialValues ...)<BR><BR>And how do you plan to represent those relations?<BR><BR>&gt; The higher object model classes (TypeDefinition, MethodDefinition,<BR>&gt; FieldDefinition ...), will have their properties access lazily those<BR>&gt; built relations in order to fetch the data on first access.<BR>&gt; My favorite solution is to write a 'ReadOnlyReflectionReader' that will<BR>&gt; contain the above changes, and leave the current implementation as is<BR>&gt; for writing purposes.<BR>&gt; I think we should also consider removing the 'sealed' modifier from the<BR>&gt; higher level object model classes (like TypeDefinition, MethodDefinition<BR>&gt; ...), by that give the used ReflectionReader full control over the<BR>&gt; object model implementation, building its own read-only one.<BR><BR>Another concern I have is Cecil's size. It's already ~360k, and I'd<BR>like to avoid bloating it.<BR><BR>&gt; Now is a good time for us to start such a process, and I would really<BR>&gt; want to push things forward.<BR><BR>I'll create a branch for Cecil so we can experiment.<BR><BR>&gt; What do you think about the suggestion?<BR>&gt; If you think about major issues that the above solution will encounter,<BR>&gt; I would be happy to hear about them.<BR><BR>I need to think more about the implications, but be sure there will be<BR>dragons :)<BR><BR>--<BR>Jb Evain&nbsp; &lt;jb@nurv.fr&gt;<BR></FONT></P></DIV></BODY></HTML>