On 19.08.2014 16:54, Kenny, Jason L wrote:
The problem for me is that we have been looking at this in our builds, but I cannot share
much. We have made prototype tools to collect this information to show within our
products. We have seen a number of issues in different area ( caching for example is a
big one. Parts and SCons both "over" cache for speed, as such waste lots of
memory and we may not be getting a real speed gain for it.) I know given a drop of SCons
with the Slots I should be able to publish some results on what we saw. The issues is
that I cannot give out our build to our products for open testing comparisons.
I think we will want some case of an open source build that is large and "real"
in that it has build dependency patterns that are real, vs something we might try to make
up. I know the builds I have are large and real, but I cannot share them. I can share
metrics at most. I sure there has to be something...
The testcase repos I setup for my speed analysis of SCons (
http://www.scons.org/wiki/WhySconsIsNotSlow ) contain several real-life
projects (open-source). And I also created a sort of test harness (some
simple Python scripts) for running them (build+update), while measuring
times and memory consumption.
All this can be found at:
http://www.bitbucket.org/dirkbaechle/scons_testsuite
I used this framework to create the numbers as published in the
pre-announcement of the switch to slots in
http://permalink.gmane.org/gmane.comp.programming.tools.scons.user/25785
, or
http://four.pairlist.net/pipermail/scons-users/2014-July/002734.html
So, the comparison you'd like to see was already performed, and the
results exist, as well as the patch. You are invited to counter-check
them on your own machines of course.
Best regards,
Dirk
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
