I don't want to make it sound like I know more than I do; the discussion on work item 20399 makes it clear that I don't accurately remember all of the specifics around this issue. But I do recall that we looked at using collectible assemblies and decided against it. We were still committed to supporting .NET 2.0 at the time, so that was one factor. But the real problem is having a realistic idea of when to stop emitting methods into assembly 1 and start emitting them into assembly 2. Having small granularity -- too many assemblies -- is a bad thing (for reasons I no longer remember). But putting too many methods into a single assembly increases the chance that the assembly will never be collected because one of its types are still in use.
Running each independent script in its own AppDomain is painful and may have performance consequences. But ultimately, it gives you the best control over resource management. On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber <m.scha...@3s-software.com>wrote: > Hi, Curt,**** > > ** ** > > Thank you for your answer. Maybe it is possible to utlilise the > Collectible Assemblies introduced with .NET 4.0 ( > http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) – > they should be fully GC-able…**** > > ** ** > > We can also live with an explicit “Dispose()”-Method to clean up artifacts > of old scripts, if that helps further…**** > > ** ** > > Best regards > > Markus Schaber > -- > ___________________________**** > > We software Automation. > > 3S-Smart Software Solutions GmbH > Markus Schaber | Developer > Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax > +49-831-54031-50 > > Email: *m.scha...@3s-software.com* | Web: http://www.3s-software.com > CoDeSys internet forum: > http://forum.3s-software.com<http://forum-en.3s-software.com/> > Download CoDeSys sample projects: > http://www.3s-software.com/index.shtml?sample_projects > > *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade > register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** ***** > > ** ** > > *Von:* Curt Hagenlocher [mailto:c...@hagenlocher.org] > *Gesendet:* Donnerstag, 18. Oktober 2012 18:01 > *An:* Markus Schaber > *Cc:* Discussion of IronPython > *Betreff:* Re: [Ironpython-users] Commercial Support / Bugfixes for > Ironpython**** > > ** ** > > This doesn't directly address your question, but as I recall, > DefineDynamicAssembly is only used under very particular circumstances. It > can be avoided most of the time in non-debug usage of IronPython. The only > way to release some of the memory usage forced by DefineDynamicAssembly is > to tear down the AppDomain and create a new one. This is a CLR issue.**** > > **** > > Disclaimer: I haven't worked on this code in about three years.**** > > On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber <m.scha...@3s-software.com> > wrote:**** > > Hi,**** > > **** > > Is it possible to hire some of the IronPython Core developers for > bugfixes, or is there commercial support available?**** > > **** > > Especially http://ironpython.codeplex.com/workitem/31764 is a major issue > for some of our users, they fight with Out of Memory exceptions during > automated test runs which fire hundreds of IronPython scripts.**** > > **** > > For us, it might be cheaper and faster to pay an expert for this task, > than trying to solve it on our own.**** > > **** > > Best regards > > Markus Schaber > -- > ___________________________**** > > We software Automation. > > 3S-Smart Software Solutions GmbH > Markus Schaber | Developer > Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax > +49-831-54031-50 > > Email: *m.scha...@3s-software.com* | Web: http://www.3s-software.com > CoDeSys internet forum: > http://forum.3s-software.com<http://forum-en.3s-software.com/> > Download CoDeSys sample projects: > http://www.3s-software.com/index.shtml?sample_projects > > *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade > register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** ***** > > **** > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > http://mail.python.org/mailman/listinfo/ironpython-users**** > > ** ** > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > http://mail.python.org/mailman/listinfo/ironpython-users > >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
