[Scons-dev] Announcement: Core changes for v2.4 ahead, Switching the Node class to using slots...

[William Blevins]

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 <vasslitvinov at 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 <alexandre at 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 <tshortik at gmx.de> a écrit :
>>
>> Alexandre,
>>
>> On 02.03.2015 09:06, alexandre.feblot at 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 at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150310/c125a061/attachment-0001.html>