Sun, 06 Nov 2016 04:36:26 +0530 py3: have bytes version of sys.argv
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 06 Nov 2016 04:36:26 +0530] rev 30340
py3: have bytes version of sys.argv sys.argv returns unicodes on Python 3. We need a bytes version for us. There was also a python bug/feature request which wanted then to implement one. They rejected and it is quoted in one of the comments that we can use fsencode() to get a bytes version of sys.argv. Though not sure about its correctness. Link to the comment: http://bugs.python.org/issue8776#msg217416 After this patch we will have pycompat.sysargv which will return us bytes version of sys.argv. If this patch goes in, i will like to make transformer rewrite sys.argv with pycompat.argv because there are lot of occurences.
Sun, 09 Oct 2016 09:00:47 -0400 util: use '\\' rather than using r'\'
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 09:00:47 -0400] rev 30339
util: use '\\' rather than using r'\' We need bytes, and I find this just a little more immediately obvious than doing rb'\'.
Sun, 09 Oct 2016 09:03:10 -0400 util: use pycompat urlunquote function
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 09:03:10 -0400] rev 30338
util: use pycompat urlunquote function
Sun, 09 Oct 2016 09:02:25 -0400 pycompat: introduce an alias for urllib.unquote
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 09:02:25 -0400] rev 30337
pycompat: introduce an alias for urllib.unquote We have to use unquote_to_bytes on Python 3, so we need an abstraction for this.
Mon, 17 Oct 2016 17:42:46 +0200 keyword: handle filectx _customcmp
Christian Ebert <blacktrash@gmx.net> [Mon, 17 Oct 2016 17:42:46 +0200] rev 30336
keyword: handle filectx _customcmp Suggested by Yuya Nishihara: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089461.html Related to issue5364.
Thu, 20 Oct 2016 22:20:31 +0900 mail: do not print(), use ui.debug() instead
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Oct 2016 22:20:31 +0900] rev 30335
mail: do not print(), use ui.debug() instead Since print() can't take a bytes output, it's pretty useless in Mercurial on Python 3. As this is a debug message, switching to ui.debug() seems fine.
Thu, 20 Oct 2016 22:12:48 +0900 progress: obtain stderr from ui
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Oct 2016 22:12:48 +0900] rev 30334
progress: obtain stderr from ui This will help Python 3 porting.
Thu, 20 Oct 2016 22:09:50 +0900 simplemerge: obtain stdout from ui
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Oct 2016 22:09:50 +0900] rev 30333
simplemerge: obtain stdout from ui This will help Python 3 porting.
Thu, 20 Oct 2016 22:07:03 +0900 profiling: obtain stderr from ui
Yuya Nishihara <yuya@tcha.org> [Thu, 20 Oct 2016 22:07:03 +0900] rev 30332
profiling: obtain stderr from ui This will help Python 3 porting.
Sun, 06 Nov 2016 18:51:57 -0800 bdiff: replace hash algorithm
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Nov 2016 18:51:57 -0800] rev 30331
bdiff: replace hash algorithm This patch replaces lyhash with the hash algorithm used by diffutils. The algorithm has its origins in Git commit 2e9d1410, which is all the way back from 1992. The license header in the code at that revision in GPL v2. I have not performed an extensive analysis of the distribution (and therefore buckets) of hash output. However, `hg perfbdiff` gives some clear wins. I'd like to think that if it is good enough for diffutils it is good enough for us? From the mozilla-unified repository: $ perfbdiff -m 3041e4d59df2 ! wall 0.053271 comb 0.060000 user 0.060000 sys 0.000000 (best of 100) ! wall 0.035827 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) $ perfbdiff 0e9928989e9c --alldata --count 100 ! wall 6.204277 comb 6.200000 user 6.200000 sys 0.000000 (best of 3) ! wall 4.309710 comb 4.300000 user 4.300000 sys 0.000000 (best of 3) From the hg repo: $ perfbdiff 35000 --alldata --count 1000 ! wall 0.660358 comb 0.660000 user 0.660000 sys 0.000000 (best of 15) ! wall 0.534092 comb 0.530000 user 0.530000 sys 0.000000 (best of 19) Looking at the generated assembly and statistical profiler output from the kernel level, I believe there is room to make this function even faster. Namely, we're still consuming data character by character instead of at the word level. This translates to more loop iterations and more instructions. At this juncture though, the real performance killer is that we're hashing every line. We should get a significant speedup if we change the algorithm to find the longest prefix, longest suffix, treat those as single "lines" and then only do the line splitting and hashing on the parts that are different. That will require a lot of C code, however. I'm optimistic this approach could result in a ~2x speedup.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip