I tried this and it actually makes a null build go slightly slower which is a
little contrary to what I expected. I'm using plain md5 decider as
Decider('md5-timestamp') checking goes horribly wrong for us.
It seems to me that this new check isn't entirely correct anyway.
Wouldn't the correct thing be to recalculate the content signature whenever you
change the file - that is to say, whenever you copy it from cache or generate
the file as the result of a build action?
Isn't that the necessary and sufficient condition?
----- Original Message -----
From: [email protected]
To: TOM TANNER (BLOOMBERG/ LONDON), [email protected]
At: Oct 2 2012 17:09:06
I believe this is a misnomer.
What it is claim is that the build started 25% early, not that it was 25%
faster. This only means that we falsely built more stuff, by making it out of
data when using a time-stamp only method for an update check. I found that
this logic did not help anything built really go faster. It only meant I build
a lot more, depending on what changed. I found that other methods gave factor
of ten or more build time speedup, and did not require build items that are up
to date.
However the reason why this did not go in, probably was that it did not get
added when we had SVN only. If you feel that this helps you out that much and
you get the speed gains you like with it.. you should resubmit this as a push
request.
Jason
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Tom Tanner (BLOOMBERG/ LONDON)
Sent: Tuesday, October 02, 2012 11:02 AM
To: [email protected]
Subject: [Scons-dev] max drift * issue 2001
There's a patch suggestion from a long time ago for getting rid of max drift
which basically returns the cached signature if and only if the timestamps are
identical with a claim of a 25% performance improvement (presumably due to not
continually calling time())
Is there any reason this patch didn't go in?
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
