On 02/12/2013 03:30 PM, Kenny, Jason L wrote:
Hi guys,
I have been looking at the memory monster that SCons can be inside my
view of the Parts addon.
On object that I get a lot of in Parts is SCons.Environment.Base
objects. Parts of this is that I make a clone based every Parts, to
prevent a huge host of problems that come from sharing environments in
different "components". It seems to me that maybe whole way we look at
Clone() is wrong. Instead of making a clean copy of all the possible
mutable values, it seems that maybe it would better to use an
OverrideEnvironment object. This would save a lot of memory. I need to
clarify this would have to be a slightly more conservative object than
the current OverrideEnvironment object in SCons in that the main issue
with using it in the current form is the code:
if "/md" in env['CPPFLAGS']:
env['CPPFLAGS'].remove(/'md')
The reason for this is that copy one write logic would not see the
remove() function being called, effecting other components that would
want the '/md' flags to exists.
To correct this one could make Scons overrides to the python object
that could notify environment that it was modify, so it make a copy of
the given object before the modification would happen. I see this is
ideal, but probably technical problematic for many different reasons.
The more realistic option I think might be to just have __getitem__
function make a copy in the overrides if the user called it ( can
probably do this with a state var, that says we are in Scons/internal
code such as subst(), vs reading a build files). Given that most of
the values are not touched by the user, only a minimum of values need
to copy, ideally a lot less that we do with a normal Clone().
Any thoughts on this? I was thinking of testing this idea in Parts. It
seems that this code would be a pretty simple object that would just
copy paste straight into Scons if I got it working.
How big are the Base objects you're seeing?
How many Clone()'s are you doing?
-Bill
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
