[IronPython] Lightweight Code Generation?
ironpython at alexh.sent.com
Sat Oct 9 10:48:22 CEST 2004
Have a long session - you'll see that "gobs" of memory can be consumed.
However, it's true that increasing memory usage in an interactive
session might be acceptable in some scenarios. But in others it might
not. That's especially the case if the product doesn't come from
My concern was not really the short interactive session, but related to
providing a solution for integrated scripting (called embedded scripting
in Python?). Where one can add functionality to an application through
scripting at runtime. If one provided a .NET language (including
Python) "script control", one would have to supply it with a warning not
to modify the script too much! Either that or implement a second
AppDomain recycling scheme that meant that the script was effectively
operating in a sandbox.
Unfortunately unloading an assembly from the primary AppDomain surely
goes beyond any member of the CLR team's influence. It is core to the
architecture of the CLR - not a feature that can just be bolted on or
included in the "next release".
To give you some idea, the whole VSA (Visual Tools for Applications)
product effectively died at the hands of this issue (and a changing ASP
market). It meant that Microsoft had to forget a run time scripting
environment and instead release a design time scripting solution -
Visual Studio Tools For Office. It's such a big issue that VBA is still
their strategic integrated scripting solution years after .NET's release.
As mentioned it's maybe worth a revisit given LCG and dynamic properties.
J. Merrill wrote:
>I agree that it's unfortunate to lose memory at each press of the Enter key, but we are not talking about gobs and gobs of memory, are we? The usefulness of the interactive mode is so much greater than the few MB of unrecoverable memory that would accumulate during a very long session. (Even if we can't recover the memory, if it gets paged out and never comes back it should not have a great impact.)
>I for one would trade "you need to exit and start again every 3 hours" for the ability to work in the dynamic, interactive, "hold the data in your hands" mode that (Iron)Python provides. The fact that we can use a great deal of what .NET has to offer (and eventually will be able to use it all) while writing in Python is great.
>The fact the MS seems to have made a poor implementation decision in the 1.x framework -- one that decrees that no code that's been loaded into an AppDomain can be unloaded without destroying the entire AppDomain -- should not prevent us from having a productive environment.
>Taking advantage of -- and perhaps enhancing prior to release -- the new functionality would be great. However, there are other things that I think are more important to be ready for an eventual 1.0 release of FePy.
>Jim is perhaps uniquely positioned to have an impact on the future course of the new capabilities. Hopefully the issues he mentioned in his other post can be resolved by changes to the CLR -- now that he's on the team.
>At 03:19 AM 10/8/2004, Alex Hoffman wrote (in part)
>>But I effectively abandoned that ... because I thought that constantly consuming (unrecoverable) memory each time someone hit the enter key was unacceptable.
>J. Merrill / Analytical Software Corp
>users-ironpython.com mailing list
>users-ironpython.com at lists.ironpython.com
More information about the Ironpython-users