[IronPython] IronPython is leaking

[Dino Viehland]

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.


-----Original Message-----
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.
>
>Martin
>
>  
>
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>());
                        code.Run(new Frame(eval));

[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?
[/end]

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.

Szymon Kobalczyk.

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com