[IronPython] IronPython is leaking
APliszka at AlienForceIT.Com
Thu Dec 22 13:08:26 CET 2005
Thanks a lot for all the suggestions.
I think IronPython is a great thing and I am looking forward for production
I am using Abstract Factory and Bridge patterns for my scripting features,
so for now I will use Boo, and as soon as IronPython 1.0 will be released I
will switch implementation to IronPython.
Once again I appreciate all the work that is being done on IronPython.
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com]On Behalf Of Szymon Kobalczyk
Sent: Wednesday, December 21, 2005 5:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython is leaking
Martin Maly wrote:
>This is a known problem in IronPython. The code generated using Evaluate is
currently not generated as garbage-collectable code. This is a something
that we have yet to fix. In the meantime what might help is pre-compiling
the code and then execute/eval the code already compiled.
Actually for Evaluate not all is lost. You can set the
IronPython.AST.Options.FastEval which causes IronPython to simply
interpret the code rather then generate IL and run it. But for other
cases the only way to limit allocations is to precompile all the scripts
and reuse them for further execution. I started similar thread last
month and here is suggested workaround:
FrameCode code = Builtin.compile(script,
"<string>", "exec") as FrameCode;
PythonModule eval = new PythonModule("<eval>",
new Dictionary<object, object>());
[This is to the IP team]
Actually this reminded me of something: In last version You made a
change that the first line doesn't return FrameCode but some other
object (FunctionCall if I remember correct) that doesn't expose any
methods to execute it. Can you fix it or provide some other alternative
to produce something executable from script?
Another reason you see IronPython allocating resources is that it builds
internal "metadata" for all assemblies it encounters. In my case this
consumes about 2MB (but this is allocated on first call only) and you
can verify this quickly with CLR Profiller. It also takes some time so
you might want to do this early on application startup instead on first
call (e.g. during some GUI action).
One more issue you might watch for is that if you pass some variables to
PythonEngine, the references these objects can be held by IronPython
even after finishing executing the script. For this I had to actually
add ClearVariables method on the Engine.
However, IronPython is so much valuable tool for us that we try to deal
with these pitfalls and use it in production system with great success.
So once again many thanks to the whole team.
users mailing list
users at lists.ironpython.com
More information about the Ironpython-users