[MonoDevelop] #D coorporation

[Ben Maurer]

Actually, i was talking about the speed of loading the db, not
generating it.

Before, there were about 10 MB of empty array lists allocated when the
cc db was loaded. 10 MB of sixteen item long object arrays that were
full of nulls. Making the array lists lazily allocated gave me a huge
startup time boost, and reduced the memory footprint.

Under mono, the cost of things should be similar. Really, you should not
have to plan for the platform -- if there is a specific api that is
acting slowly, I can take a look at it. For example, MD/#D has already
found one area where System.Reflection was pretty slow -- gonzalo fixed
it in a few minutes.

Now, there is one exception which is the GC in mono. Right now, we use a
non-moving GC, which means we do not do generational collection. What
does this mean for you? It means that allocating objects and letting
them die off very quickly will have much more of a hit in Mono than
under MS. Note that reducing the number of young objects is probably
going to help no matter what the GC model. It is not free to do a gen0
collection under MS, however it is pretty cheep.

WRT to the string hack you were talking about, as I understand it, you
are doing some form of interning. This may or may not help, depending on
how many strings are being duplicated. Zoltan made a patch for mcs that
did some of this and it worked with great success. Probably the bigger
beneift is that you would be able to do comparisons with pointer
comparisons, rather than string comparisons.

And I agree, we need to communicate more. I like John's idea of having
our discuessions about features/directions on a communal list. Also,
being able to see the svn progress on a -patches like list would be
nice.

-- Ben
>>> Mike Krueger <mike@icsharpcode.net> 03/19/04 11:37 AM >>>
Hi

I'll look at the changes :)
I've switched to 'fast' creation only and took out the 'slow' creation 
... but the code completion database
generally is a difficult issue:

- Is this 'really' needed ?
- How large is the memory footprint of holding the code completion 
information under mono ?
- When it is better using a code completion database how about using it 
for whole combines
-> no need to reload all the project files each time ... maybe it can be

made intelligent storing for each
file the size & date and if that differs the file is reparsed ?

... I've changed the parser layer a little so that the 'high-level' AST 
doesn't hold strings. Instead it now
stores all fully qualified names in a hashtable and each object just 
gets the 'hash code' (1 int) instead of
the fully qualified name string. But under MS .NET I've not noticed any 
memory or performance gain
using this approach.

Generally it is good if you question the #Develop design decisions but 
we should communicate a lot more.
I've made some nice features lately that MonoDevelop can use too ... 
like file templates :)

... one thing: The PropertyGrid would be really, really useful under 
windows is anybody working on this control?

Regards
Mike

>I very much like the idea of a common reprository for MonoDevelop and
>SharpDevelop. This would sure make it easier to do stuff. We should
work
>to identify this base code, make sure there are no dependencies other
>than the standard classlibs (no system.drawing stuff, etc).
>
>The parser is pretty fast, however when I worked on some large files
>(the mcs compiler has some that are > 100kb), I had some trouble. Note
>that I have a pretty slow computer (sub-gigahertz), but when I run
>Visual Studio.net on a computer with a windows computer that has a
>slower CPU and half of the ram i have (I have 512), I was able to edit
>the MCS files with ease. Also, it took quite a while for me to load
>corlib.
>
>There are also some major performance enhancements in our svn, I did
>alot of work early on to reduce the speed of loading the code
completion
>database. Feel free to steal^H^H^H^H^Hreuse my work, the patches should
>be small enough that copyright assignment is not needed. (Code
>Completion database is another area we can share code in).
>
>-- Ben
>
>  
>
>>>>Mike Krueger <mike@icsharpcode.net> 03/19/04 10:12 AM >>>
>>>>        
>>>>
>Hi
>
>  
>
>>I think you have a very good point about namespaces. I for one would
>>vote reverting any namespace changes for code that can be shared
>>    
>>
>between
>  
>
>>versions.
>>
>>I really hope we can share code parsing stuff between the IDEs, there
>>    
>>
>is
>  
>
>>no reason it cant be done. I have been thinking about doing some work
>>    
>>
>in
>  
>
>>the parser area, and I would love to see it shared. The expression
>>finder thing you talk about is one of the things I was going to do --
i
>>would love to see it merged in to MD.
>>
>> 
>>
>>    
>>
>Maybe we should have >common< repositories for some code ? I think a  
>fair amount of the 'base' code
>(and the core of course :))  could be used for both projects.
>
>  
>
>>I had a few ideas, I hope you can take them as food for thought. It is
>>unlikely I could really dive into the parser for a few months, so if
>>    
>>
>any
>  
>
>>of these ideas seem easy to do, please feel free to steal them:
>>
>> 
>>
>>    
>>
>I don't steal I re-use :)
>
>  
>
>>Also, I have been thinking about performance and if it is possible to
>>parse less stuff then we do now (eg, only parse the method your cursor
>>is in when you are typing).
>>
>> 
>>
>>    
>>
>I thought about this too ... but currently I'm having to do in other 
>areas :) and the parser process is relative
>fast but parsing only the changes is better.
>
>Regards
>Mike
>
>_______________________________________________
>Monodevelop-list mailing list
>Monodevelop-list@lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
>
>
>  
>


_______________________________________________
Monodevelop-list mailing list
Monodevelop-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-list