Mon, 13 Mar 2017 18:16:42 -0700 perf: perform a garbage collection before each iteration
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 13 Mar 2017 18:16:42 -0700] rev 31406
perf: perform a garbage collection before each iteration Currently, no explicit garbage collection is performed when running the microbenchmarks in `hg perf`. I think this is wrong because garbage collection can have a significant impact on execution times. And, if gc is triggered via the default heuristics, it will fire effectively randomly during subsequent benchmark iterations due to variable amount of garbage left over from previous runs. Running a gc before invoking the measured function will help ensure state is more consistent across all iterations.
Mon, 13 Mar 2017 18:31:29 -0700 formatter: support json formatting of long type
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 13 Mar 2017 18:31:29 -0700] rev 31405
formatter: support json formatting of long type By luck, we appear to not pass any long instances into the JSON formatter. I suspect this will change with all the Python 3 porting work. Plus I have another series that will convert some ints to longs that triggers this.
Sun, 12 Mar 2017 21:56:39 -0700 rebase: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:56:39 -0700] rev 31404
rebase: don't use mutable default argument value
Sun, 12 Mar 2017 21:55:46 -0700 mq: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:55:46 -0700] rev 31403
mq: don't use mutable default argument value
Sun, 12 Mar 2017 21:54:32 -0700 util: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:54:32 -0700] rev 31402
util: don't use mutable default argument value I don't think this is any tight loops and we'd need to worry about PyObject creation overhead. Also, I'm pretty sure strptime() will be much slower than PyObject creation (date parsing is surprisingly slow).
Sun, 12 Mar 2017 21:53:03 -0700 match: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:53:03 -0700] rev 31401
match: don't use mutable default argument value There shouldn't be a big perf hit creating a new object because this function is complicated and does things that dwarf the cost of creating a new PyObject.
Sun, 12 Mar 2017 21:52:17 -0700 hgweb: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:52:17 -0700] rev 31400
hgweb: don't use mutable default argument value
Mon, 26 Dec 2016 16:55:47 -0700 hgweb: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Dec 2016 16:55:47 -0700] rev 31399
hgweb: don't use mutable default argument value
Mon, 26 Dec 2016 16:54:33 -0700 filemerge: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 26 Dec 2016 16:54:33 -0700] rev 31398
filemerge: don't use mutable default argument value
Sun, 12 Mar 2017 21:50:42 -0700 context: don't use mutable default argument value
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 12 Mar 2017 21:50:42 -0700] rev 31397
context: don't use mutable default argument value Mutable default argument values are a Python gotcha and can represent subtle, hard-to-find bugs. Lets rid our code base of them.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip