Fri, 12 Jan 2018 11:09:04 +0000 visibility: fix a comment introduced before which is not up-to-date
Boris Feld <boris.feld@octobus.net> [Fri, 12 Jan 2018 11:09:04 +0000] rev 35608
visibility: fix a comment introduced before which is not up-to-date 265cd9e19d26 introduced a comment in _filterederror that was not updated with the latest iterations of the patch, fix the comment. Differential Revision: https://phab.mercurial-scm.org/D1851
Wed, 10 Jan 2018 19:24:58 -0800 rust: avoid redundant 'static lifetime
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Jan 2018 19:24:58 -0800] rev 35607
rust: avoid redundant 'static lifetime 'static is apparently automatic for const variables. Differential Revision: https://phab.mercurial-scm.org/D1846
Thu, 11 Jan 2018 11:57:59 +0000 pull: hold wlock for the full operation when --update is used
Boris Feld <boris.feld@octobus.net> [Thu, 11 Jan 2018 11:57:59 +0000] rev 35606
pull: hold wlock for the full operation when --update is used With now, the wlock is not held between the pull and the update. This can lead to race condition and make logic checking to post pull results more complicated (eg: with _afterlock).
Thu, 11 Jan 2018 18:20:08 +0800 hgweb: drop support of browsers that don't understand <canvas> (BC)
Anton Shestakov <av6@dwimlabs.net> [Thu, 11 Jan 2018 18:20:08 +0800] rev 35605
hgweb: drop support of browsers that don't understand <canvas> (BC) Internet Explorer 8 and below need excanvas aka ExplorerCanvas to support canvas tag at all. We used to vendor the library in Mercurial, but IE8 was discontinued and all support for it ceased in January 2016. We should do the same and remove excanvas library. Apart from just cleaning up code, this will also make downstream Debian packages stop depending on libjs-excanvas, for example.
Wed, 10 Jan 2018 19:36:45 -0800 rust: add TODO about lifetime of program_name variable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Jan 2018 19:36:45 -0800] rev 35604
rust: add TODO about lifetime of program_name variable Per review comment in D1581. Differential Revision: https://phab.mercurial-scm.org/D1847
Wed, 10 Jan 2018 19:23:36 -0800 rust: move import of PathBuf
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Jan 2018 19:23:36 -0800] rev 35603
rust: move import of PathBuf By moving it to the single function that uses it, we eliminate a #cfg. Differential Revision: https://phab.mercurial-scm.org/D1845
Wed, 10 Jan 2018 21:09:57 -0800 perf: do not import util.queue
Jun Wu <quark@fb.com> [Wed, 10 Jan 2018 21:09:57 -0800] rev 35602
perf: do not import util.queue This was added by af25237be091. But util.queue is not a module and is not importable. I guess it wasn't noticed because of demandimport. Differential Revision: https://phab.mercurial-scm.org/D1848
Wed, 10 Jan 2018 19:08:51 -0800 rust: move Cargo.lock
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Jan 2018 19:08:51 -0800] rev 35601
rust: move Cargo.lock If you do a `cargo build` in rust/, Cargo will create rust/Cargo.lock. Furthermore, the previous rust/hgcli/Cargo.lock appears to not even be consulted because the auto-generated rust/Cargo.lock varied from rust/hgcli/Cargo.lock. This commit moves Cargo.lock to where Cargo expects it to be. While we're here, bump the version of libc to the latest available. Differential Revision: https://phab.mercurial-scm.org/D1844
Wed, 10 Jan 2018 19:04:52 -0800 run-tests: fix regular expression for path test
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Jan 2018 19:04:52 -0800] rev 35600
run-tests: fix regular expression for path test The previous regexp would match the empty string. This fixes a mistake added in 964212780daf. Differential Revision: https://phab.mercurial-scm.org/D1843
Sun, 17 Dec 2017 04:31:27 +0100 perf: add threading capability to perfbdiff
Boris Feld <boris.feld@octobus.net> [Sun, 17 Dec 2017 04:31:27 +0100] rev 35599
perf: add threading capability to perfbdiff Since we are releasing the GIL during diffing, it is interesting to see how a thread pool would perform on diffing. We add a new `--threads` argument to commands. Synchronizing the thread pool is a bit complex because we want to be able to reuse it from one run to another. On my computer (i7 with 4 cores + hyperthreading), I get the following data for about 12000 revisions: threads wall comb wall gain comb overhead none 31.596715 31.59 0.00% 0.00% 1 31.621228 31.62 -0.08% 0.09% 2 16.406202 32.8 48.08% 3.83% 3 11.598334 34.76 63.29% 10.03% 4 9.205421 36.77 70.87% 16.40% 5 8.517604 42.51 73.04% 34.57% 6 7.94645 47.58 74.85% 50.62% 7 7.434972 51.92 76.47% 64.36% 8 7.070638 55.34 77.62% 75.18% Compared to the feature disabled (threads=0), the overhead is negligible with the threading code (threads=1), and the gain is already 48% with two threads.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip