All, After running the slots branch against one of my real world test cases, I saw ~10-11% memory overhead reduction and ~3% total build speed.
I will work on getting performance logs for the scons_testresults repo. V/R, William On a side note, there was only one line I needed to change for the node class variables to functions, but I can understand that tools will take a big hit, though all cases will be strictly find and replace. I ran into similar problems when working on the cross-language scanner issues. A lot of core SCons code has traditionally used public variables rather than getter/setter mechanisms which makes any sort of refactor effort extremely difficult without breaking backwards compatibility. I would be well enough to override getattr to make the current variables simply return the function results. This would resolve backwards compatibility until tools could be updated though at a marginal performance hit. I think that moving to getters/setters is the right move in general. Encapsulation solves a lot of refactor heartburn. On Mon, Mar 2, 2015 at 3:32 PM, Vasily <vasslitvi...@pisem.net> wrote: > Hi everyone, > > Why cannot .path, .abspath, etc. become properties (with getters set to > .get_path, .get_abspath, etc)? What's the need to break existing API? I > think there're TONS of files which are using those functions... and > thinking about patching all those makes me really sad :( > > Thanks, > Vasily > > 2015-03-02 12:14 GMT+03:00 <alexan...@feblot.fr>: > >> Hum, >> >> in fact, 1 and 3 and also the idea to checkin Scons 2.3 in our current >> code (as well as all maintenance branches) are equivalent, and painful: We >> have many maintenance branches, and hundreds of tags that potentially may >> have to be checked out again and recompiled. >> >> 2 seems to be the only actual solution in order to keep all existing code >> working. >> >> However, what would you think about such implementation which keeps >> compatible with current code: >> >> - rename private attributes. example: abspath -> private_abspath >> - for new code, use new interface. example: get_abspath() { return >> self.private_abspath } >> - for old code, allow using the old private attribute thanks to >> __getattr__(): >> >> >> class Node: >> >> __slots__ = ('private_abspath') >> >> def __init__(self): >> self.private_abspath = None >> >> def get_abspath(self): >> self.private_abspath = "/a/path" # Lazy initialization >> return self.private_abspath >> >> def __getattr__(self, attr): >> if attr == "abspath": >> print "warning: abspath supported only for API consistency >> with peformance loss. Use get_abspath()" # in real class,this warning >> should only be printed once. >> return self.get_abspath() >> >> >> n = Node() >> print n.get_abspath() >> print n.abspath >> >> result: >> >> /a/path >> warning: abspath supported only for API consistency with peformance loss. >> Use get_abspath() >> /a/path >> >> Note: I always considered .path and .abspath as public API as they are >> documented and used in many examples in the documentation. Was that a wrong >> assumption? >> >> >> >> >> Le 2 mars 2015 à 09:30, Dirk Bächle <tshor...@gmx.de> a écrit : >> >> Alexandre, >> >> On 02.03.2015 09:06, alexandre.feb...@gmail.com wrote: >> >> Hi Dirk, >> >> About those new interfaces for accessing node attributes that may get >> initialized lazily, do I understand here the consequences properly? >> >> - Using directly a_node.path or a_node.abspath *must* be replaced in all >> SConstructs/SConscripts by the new interfaces if we wan’t them to keep >> working properly >> - This lets us with 2 solutions: >> 1- Do these changes in all our product maintenance branches, and even >> each time we need to checkout again an old tag we want to compile again. >> 2- Keep an old Scons 2.3 to build our old code, and change our build >> infrastructure to be able to have different SCons paths, so we can chose >> the proper one. >> >> >> sorry, I forgot: >> >> 3- Factor out all your direct accesses to Node internals into a >> custom module/Builder, and then wrap it with a check for the SCons version. >> For 2.3.x and smaller, you access Node attributes as before, and for the >> newer versions you then branch to using the getter methods. >> >> This is pretty much what the compat layer would do, which I mentioned in >> my last reply. >> >> Best regards, >> >> Dirk >> >> >> _______________________________________________ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> >> >> _______________________________________________ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev