[IronPython] IronPython is leaking
dinov at exchange.microsoft.com
Tue Dec 27 11:11:14 PST 2005
Regarding the FunctionCall / FrameCode change...
This is great feedback. One of the work items we have before the next release is to review & better define the public API surface. Any other feedback you (or anyone else) have on this would be great.
Ultimately the public API surface should all be contained within the IronPython.Hosting namespace. The rest of the "public" functionality is really just our runtime. It'd be great to hear if there are other areas where the "non-public" API surface is being used so that we can make sure that there is supported functionality within Hosting that covers that. Obviously using the non-public API surface is a great workaround until we get this all settled.
We'll look into providing something reasonable here for this specific scenario for the next release.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Szymon Kobalczyk
Sent: Wednesday, December 21, 2005 2: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 users