SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search

#Develop memory consumption - Whatever happened to ClassProxies?

Last post 04-12-2011 7:08 PM by DanielGrunwald. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 04-12-2011 4:08 PM

    #Develop memory consumption - Whatever happened to ClassProxies?

    Hi all,

    I'm using NRefactory and SharpDevelopDom (and especially the Resolver) in an enviorment where memory consumption is a big issue.

    I read in the "Dissecting a C# Application" book about the the design that used proxy classes to conserve memory for the BCL's DOM information, but I found no traces of this design in the current source code, so I assume this mechanism was removed some time along the way - 

    my question is, why was it removed? If I were to try and put a similar mechanism back in place (both for my own use and as a patch), what obstables might I face?

    Thanks a lot!

  • 04-12-2011 7:08 PM In reply to

    Re: #Develop memory consumption - Whatever happened to ClassProxies?

    I'm not sure why it was removed - Mike did this very early in the SharpDevelop 2.0 development. I had to re-add a database-like approach for the .xml documentation, as those were using almost 100 MB.

    But note that the old database implementation was limited to a single database which contained all the (.NET 1.0) framework assemblies. Other referenced assemblies were not using the database. And code completion would always show the complete DB contents. The SD 1.x project system was implicitly referencing all framework assemblies. This changed with SD 2.0, where we started using MSBuild which uses explicit references to the .NET assemblies.

    The DOM rewrite for SD 5.0 introduces some improvements in memory usage - for example, we now 'intern' identicial objects (e.g. two parameters with the same type and name; or two identical attributes).

    For example, here are some framework assemblies, and the size of their DOM information in the new system:

    • mscorlib - 1985 KB
    • System - 1308 KB
    • System.Core - 566 KB
    • System.Xml - 417 KB
    • System.Xml.Linq - 87 KB
    • System.Data - 552 KB
    • System.Drawing - 456 KB
    • System.Windows.Forms - 1650 KB
    • WindowsBase - 284 KB
    • PresentationCore - 1355 KB
    • PresentationFramework - 1228 KB

    All together, that's takes less than 10 MB, even a bit smaller than the metadata-only assemblies in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0. So I think it's not worth the effort to write/maintain any sort of proxy class system.

    I don't know how much memory the DOM in SD 4.0 consumes for the assemblies listed above, but I would expect it to be significantly more, as it hardly does any interning optimizations.

    As for the challenges: if you reimplement something like this, you need to be careful how you are going to access the disk when loading classes on demand. Searching extension methods in all static classes could cause a very noticable delay if you read each class individually (so have to wait for the hard-disk to seek to each class) - you'd want to read whole sectors and keep them cached, or probably use some existing database engine to handle this task for you.

Page 1 of 1 (2 items)
Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this (fleischfalle@alphasierrapapa.com) email address.