What is the impact of caching CompiledCode into this "collectability" issue?
I am working on a CMS that expose functions implemented in IronPython to a template engine. So I read a directory of 40 or 50 xx.py files, load it up and compiled them. This is off course a costly operation to do it in every single HTTP request (and SLOW) so I compiled the source code to CompiledCode and cache them. Then for every HTTP request, I retrieve these CompiledCode's from the Cache and call Execute(scope) to make the frozen code to be a real function. So with X HTTP request, there will be X scope and (X * 40) functions being generated at runtime. Now our memory consumption is huge and is getting bigger until IIS gave up and recycle the process. Dody G. > Just some comments on this as there’s a few issues intertwined here: > > 1. Optimized code – this is currently the default and part of the > original problem. If you execute code in “optimized” mode we generate an > uncollectible type. In 2.6 I’m switching the default to be non-optimized > and I also am trying out a change that should reduce the amount of leakage > when we do this. That will make the out of the box experience much better. > > 2. Multiple script runtimes – there’s a bug in the DLR when you > repeatedly create script runtimes that the rules aren’t getting collected. > This is supposed to be fixed in 2.6 but I’m still seeing some leaks in this > scenario that I’ll look into and fix. Back-porting this to 2.0 would be > quite difficult as a lot of things have changed but we could certainly look > at backporting a different fix to 2.0. > > 3. There’s a repro that defines “TestScriptOldClass” + n which leaks. > All class / function / member names in code get interned and this is where > this leak is coming from. If you remove the + n then everything works. We > may get rid of this interning at some point in the future but it’s a fairly > significant change. I’m inclined to believe this one isn’t as much of an > issue as usually you aren’t compiling code with new names every single > type. > > > > From: users-boun...@lists.ironpython.com > [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata > Sent: Sunday, February 22, 2009 2:10 PM > To: Discussion of IronPython > Subject: [IronPython] Please vote up this DLR memory leak bug > > > > There's only 5 votes so far. > > > > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399 > > > > -- > nomadlife.org -- nomadlife.org _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
