- Oct 01, 2020
-
-
Pierre-Yves David authored
Changeset centric copy tracing now use the rust code. The rust code focussed on simplicity and will be optimised later. So the performance is not great yet. Now that all the pieces are in place we can start working on performance in the coming changesets. Below is a table that summarize how slower we got: Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000049 s, 0.000046 s, -0.000003 s, × 0.9388 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000112 s, 0.000173 s, +0.000061 s, × 1.5446 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.004216 s, 0.006303 s, +0.002087 s, × 1.4950 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000204 s, 0.000229 s, +0.000025 s, × 1.1225 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000058 s, 0.000056 s, -0.000002 s, × 0.9655 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000112 s, 0.000143 s, +0.000031 s, × 1.2768 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.000339 s, 0.001166 s, +0.000827 s, × 3.4395 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.010214 s, 0.022931 s, +0.012717 s, × 2.2451 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.047497 s, 0.852446 s, +0.804949 s, × 17.9474 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.075297 s, 2.221824 s, +2.146527 s, × 29.5075 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.057322 s, 1.194162 s, +1.136840 s, × 20.8325 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.796264 s, 62.468362 s, +61.672098 s, × 78.4518 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.020491 s, 0.022116 s, +0.001625 s, × 1.0793 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.121612 s, 2.972788 s, +2.851176 s, × 24.4449 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000143 s, 0.000180 s, +0.000037 s, × 1.2587 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000112 s, 0.000123 s, +0.000011 s, × 1.0982 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000232 s, 0.000315 s, +0.000083 s, × 1.3578 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.000721 s, 0.001297 s, +0.000576 s, × 1.7989 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.010115 s, 0.024884 s, +0.014769 s, × 2.4601 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.015461 s, 0.032653 s, +0.017192 s, × 2.1120 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.060756 s, 4.230118 s, +4.169362 s, × 69.6247 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 0.605842 s, killed mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000164 s, 0.000197 s, +0.000033 s, × 1.2012 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000331 s, 0.000622 s, +0.000291 s, × 1.8792 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000249 s, 0.000296 s, +0.000047 s, × 1.1888 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.000711 s, 0.001626 s, +0.000915 s, × 2.2869 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.003438 s, 0.006218 s, +0.002780 s, × 1.8086 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.069869 s, 0.132760 s, +0.062891 s, × 1.9001 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.005701 s, 0.029001 s, +0.023300 s, × 5.0870 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.005757 s, 0.005886 s, +0.000129 s, × 1.0224 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.061826 s, 3.619850 s, +3.558024 s, × 58.5490 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.043354 s, 0.058678 s, +0.015324 s, × 1.3535 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.198979 s, 11.926587 s, +11.727608 s, × 59.9389 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 2.067096 s, killed mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 3.102616 s, killed mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001212 s, 0.001204 s, -0.000008 s, × 0.9934 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001237 s, 0.001217 s, -0.000020 s, × 0.9838 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000557 s, 0.000605 s, +0.000048 s, × 1.0862 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001532 s, 0.001876 s, +0.000344 s, × 1.2245 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.035166 s, 0.078190 s, +0.043024 s, × 2.2235 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.070336 s, 0.135428 s, +0.065092 s, × 1.9254 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.006080 s, 0.029123 s, +0.023043 s, × 4.7900 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.006099 s, 0.006141 s, +0.000042 s, × 1.0069 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.064317 s, 4.857827 s, +4.793510 s, × 75.5294 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.303263 s, 10.674920 s, +10.371657 s, × 35.2002 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.292804 s, 9.789462 s, +9.496658 s, × 33.4335 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.107594 s, 1.087890 s, +0.980296 s, × 10.1111 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.045202 s, 0.060556 s, +0.015354 s, × 1.3397 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 1.926277 s, killed mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 0.794492 s, killed mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 84.521497 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 0.965937 s, 19.647038 s, +18.681101 s, × 20.3399 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 83.367146 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 84.260895 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 3.274537 s, killed mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 42.235843 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 49.872829 s, killed Differential Revision: https://phab.mercurial-scm.org/D9299
-
Pierre-Yves David authored
This patch focus on the `hg-cpython` part of this work. Bridging the python code with the new rust code in `hg-core`. The next patch will actually plug this in the python code. The rust code use multiple Python callback, python related error within this callback are not expected unless they are a programming error or a data corruption. In addition, these callback will slowly be replaced by native Rust code. For these reasons, we use will deal with unexpected error within this callback using rust Panic and let the `rust-cpython` layer deal with raising a Python exception. The code dealing with the ChangedFile instance is repeating itself a lot. I did not factor these duplication out because that whole code will get replaced by entirely different one in a handful of changesets. Differential Revision: https://phab.mercurial-scm.org/D9298
-
Pierre-Yves David authored
This new function mirror the python code. This first implementation does a lot of data copies and is therefore quite slow. However my goal here is to create a simple "frame" from where to start adding optimization. This patch focus on the `hg-core` part of this work. Coming patches will do the necessary `hg-cpython` work to be able to use this from Python. Differential Revision: https://phab.mercurial-scm.org/D9297
-
- Nov 02, 2020
-
-
Pierre-Yves David authored
A good share of the time spent in this function is spent doing ancestors checking. To avoid spending time in duplicated call, we cache the result of calls. In the slower case, this provide a quite significant performance boost. Below are the result for a set of selected pairs (many of them pathological): (And further down is another table that summarize the current state of filelog based vs changeset base copy tracing) The benchmark have been configured to be killed after 6 minutes of runtime, which mean that any detect slower than 2 minutes will be marked as "killed". This drop some useful information about how much slower these case are… but also prevent 99% of the benchmark time to be spent on case that can be labelled "very slow" anyway. Repo Case Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000044 s, 0.000044 s, +0.000000 s, × 1.0000 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000138 s, 0.000138 s, +0.000000 s, × 1.0000 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.005067 s, 0.005052 s, -0.000015 s, × 0.9970 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000218 s, 0.000219 s, +0.000001 s, × 1.0046 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000053 s, 0.000055 s, +0.000002 s, × 1.0377 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000125 s, 0.000128 s, +0.000003 s, × 1.0240 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001098 s, 0.001089 s, -0.000009 s, × 0.9918 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.017546 s, 0.017407 s, -0.000139 s, × 0.9921 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.096723 s, 0.094175 s, -0.002548 s, × 0.9737 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.271796 s, 0.238009 s, -0.033787 s, × 0.8757 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.128602 s, 0.125876 s, -0.002726 s, × 0.9788 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 7.086742 s, 3.581556 s, -3.505186 s, × 0.5054 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.016634 s, 0.016721 s, +0.000087 s, × 1.0052 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.254225 s, 0.242367 s, -0.011858 s, × 0.9534 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000166 s, 0.000165 s, -0.000001 s, × 0.9940 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000118 s, 0.000114 s, -0.000004 s, × 0.9661 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000296 s, 0.000296 s, +0.000000 s, × 1.0000 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001137 s, 0.001124 s, -0.000013 s, × 0.9886 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.014133 s, 0.013060 s, -0.001073 s, × 0.9241 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.016988 s, 0.017112 s, +0.000124 s, × 1.0073 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.676361 s, 0.660350 s, -0.016011 s, × 0.9763 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 12.515149 s, 10.032499 s, -2.482650 s, × 0.8016 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000186 s, 0.000189 s, +0.000003 s, × 1.0161 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000459 s, 0.000462 s, +0.000003 s, × 1.0065 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000273 s, 0.000270 s, -0.000003 s, × 0.9890 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001503 s, 0.001474 s, -0.000029 s, × 0.9807 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.004862 s, 0.004806 s, -0.000056 s, × 0.9885 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.088291 s, 0.085150 s, -0.003141 s, × 0.9644 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007113 s, 0.007064 s, -0.000049 s, × 0.9931 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004687 s, 0.004741 s, +0.000054 s, × 1.0115 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.198710 s, 0.190133 s, -0.008577 s, × 0.9568 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.036068 s, 0.035651 s, -0.000417 s, × 0.9884 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.465362 s, 0.440694 s, -0.024668 s, × 0.9470 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 24.519684 s, 18.454163 s, -6.065521 s, × 0.7526 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 42.711897 s, 31.562719 s, -11.149178 s, × 0.7390 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001201 s, 0.001189 s, -0.000012 s, × 0.9900 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001216 s, 0.001204 s, -0.000012 s, × 0.9901 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000595 s, 0.000586 s, -0.000009 s, × 0.9849 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001856 s, 0.001845 s, -0.000011 s, × 0.9941 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.064936 s, 0.063822 s, -0.001114 s, × 0.9828 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.090601 s, 0.088038 s, -0.002563 s, × 0.9717 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007510 s, 0.007389 s, -0.000121 s, × 0.9839 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004911 s, 0.004868 s, -0.000043 s, × 0.9912 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.233231 s, 0.222450 s, -0.010781 s, × 0.9538 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.419989 s, 0.370675 s, -0.049314 s, × 0.8826 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.401521 s, 0.358020 s, -0.043501 s, × 0.8917 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.179555 s, 0.145235 s, -0.034320 s, × 0.8089 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.038004 s, 0.037606 s, -0.000398 s, × 0.9895 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 52.838482 s, 7.382439 s, -45.456043 s, × 0.1397 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 8.705874 s, 7.273506 s, -1.432368 s, × 0.8355 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.126708 s, 1.074593 s, -0.052115 s, × 0.9537 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 83.854020 s, 27.746195 s, -56.107825 s, × 0.3309 Below is a table comparing the runtime of the current "filelog centric" algorithm, with the "changeset centric" one, we just modified. The changeset centric algorithm is a significant win in many scenario, but they are still various cases where it is quite slower. When many revision has to be considered the cost of retrieving the copy information, creating new dictionaries, merging dictionaries and checking if revision are ancestors of each other can slow things down. The rest of this series, will introduce a rust version of the copy tracing code to deal with most of theses issues. Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor --------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000914 s, 0.000044 s, - 0.000870 s, × 0.048140 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.001812 s, 0.000138 s, - 0.001674 s, × 0.076159 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.017954 s, 0.005052 s, - 0.012902 s, × 0.281386 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.001509 s, 0.000219 s, - 0.001290 s, × 0.145129 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.206881 s, 0.000055 s, - 0.206826 s, × 0.000266 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.016951 s, 0.000128 s, - 0.016823 s, × 0.007551 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.019096 s, 0.001089 s, - 0.018007 s, × 0.057028 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.762506 s, 0.017407 s, - 0.745099 s, × 0.022829 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 1.179211 s, 0.094175 s, - 1.085036 s, × 0.079863 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 1.249058 s, 0.238009 s, - 1.011049 s, × 0.190551 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 1.614107 s, 0.125876 s, - 1.488231 s, × 0.077985 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.001064 s, 3.581556 s, + 3.580492 s, × 3366.124060 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 1.061275 s, 0.016721 s, - 1.044554 s, × 0.015756 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.341119 s, 0.242367 s, - 1.098752 s, × 0.180720 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.027803 s, 0.000165 s, - 0.027638 s, × 0.005935 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.130014 s, 0.000114 s, - 0.129900 s, × 0.000877 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.024990 s, 0.000296 s, - 0.024694 s, × 0.011845 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.052201 s, 0.001124 s, - 0.051077 s, × 0.021532 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.037642 s, 0.013060 s, - 0.024582 s, × 0.346953 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.197086 s, 0.017112 s, - 0.179974 s, × 0.086825 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.935148 s, 0.660350 s, - 0.274798 s, × 0.706145 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 3.920674 s, 10.032499 s, + 6.111825 s, × 2.558871 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.024232 s, 0.000189 s, - 0.024043 s, × 0.007800 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.141483 s, 0.000462 s, - 0.141021 s, × 0.003265 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.025775 s, 0.000270 s, - 0.025505 s, × 0.010475 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.084922 s, 0.001474 s, - 0.083448 s, × 0.017357 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.194784 s, 0.004806 s, - 0.189978 s, × 0.024673 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.161103 s, 0.085150 s, - 2.075953 s, × 0.039401 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089347 s, 0.007064 s, - 0.082283 s, × 0.079063 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.732171 s, 0.004741 s, - 0.727430 s, × 0.006475 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 1.157287 s, 0.190133 s, - 0.967154 s, × 0.164292 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.726568 s, 0.035651 s, - 6.690917 s, × 0.005300 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 3.266229 s, 0.440694 s, - 2.825535 s, × 0.134924 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 15.860534 s, 18.454163 s, + 2.593629 s, × 1.163527 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 20.450475 s, 31.562719 s, +11.112244 s, × 1.543373 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.080442 s, 0.001189 s, - 0.079253 s, × 0.014781 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.497672 s, 0.001204 s, - 0.496468 s, × 0.002419 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.021183 s, 0.000586 s, - 0.020597 s, × 0.027664 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.230991 s, 0.001845 s, - 0.229146 s, × 0.007987 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1.118461 s, 0.063822 s, - 1.054639 s, × 0.057062 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.206083 s, 0.088038 s, - 2.118045 s, × 0.039907 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089404 s, 0.007389 s, - 0.082015 s, × 0.082647 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.733043 s, 0.004868 s, - 0.728175 s, × 0.006641 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 1.163367 s, 0.222450 s, - 0.940917 s, × 0.191212 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.085456 s, 0.370675 s, + 0.285219 s, × 4.337612 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.083601 s, 0.358020 s, + 0.274419 s, × 4.282485 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 7.366614 s, 0.145235 s, - 7.221379 s, × 0.019715 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.664464 s, 0.037606 s, - 6.626858 s, × 0.005643 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.467836 s, 7.382439 s, - 0.085397 s, × 0.988565 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 9.801294 s, 7.273506 s, - 2.527788 s, × 0.742097 mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 0.091886 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 26.491140 s, 1.074593 s, -25.416547 s, × 0.040564 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 0.092863 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 0.226823 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 18.914630 s, 27.746195 s, + 8.831565 s, × 1.466917 mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 21.198903 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 24.952268 s, killed Differential Revision: https://phab.mercurial-scm.org/D9296
-
- Oct 13, 2020
-
-
Pierre-Yves David authored
See test documentation for details. This is yet another corner case for copy tracing. Differential Revision: https://phab.mercurial-scm.org/D9200
-
- Oct 21, 2020
-
-
Jörg Sonnenberger authored
The memorytop function uses Python's tracemalloc module to show the source lines / backtraces with the largest remaining allocations. This allows identifying the origins of active memory by placing calls in strategic locations. Allocations from C extensions will show up as long as they are using the Python allocators. Differential Revision: https://phab.mercurial-scm.org/D9236
-
- Oct 29, 2020
-
-
Martin von Zweigbergk authored
I left out branches and custom namespaces on purpose from D9252 because I figured that people like us (Google) who have custom namespaces can also have custom configs. However, I just realized that this makes everyone with the topic extension lose the topic they've had in rebase output for a long time (ever since someone was nice enough to add it in D741). Sorry about the churn. The more generic template couldn't easily keep the "log.bookmark" label in the template because the namespace is called "bookmarks" (plural). That means that we can't be compatible with users' existing configs for "log.bookmark", so I decided to change the labels to be in a brand-new "oneline-summary" namespace. Differential Revision: https://phab.mercurial-scm.org/D9262
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9258
-
Martin von Zweigbergk authored
-
- Oct 24, 2020
-
-
Matt Harbison authored
I noticed after doing an update from an obsolete revision with a dirty wdir that the obsolete commit stayed visible for no obvious reason. It was decided in 85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in order to allow re-resolving. Since the point of pinning the obsolete parents was to allow resolving in the first place (aaeccdb6e654), it makes sense to also gate it on whether or not there are any remaining files to resolve. This might result in pinning again if files are marked unresolved again, but that seems reasonable, given that it still solves the original issue. Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is likely to cause complaints about pushing multiple heads or other unexpected errors. So the faster it comes out of that state, the better. Differential Revision: https://phab.mercurial-scm.org/D9248
-
- Oct 28, 2020
-
-
Dan Villiom Podlaski Christiansen authored
Differential Revision: https://phab.mercurial-scm.org/D9256
-
- Oct 23, 2020
-
-
Yuya Nishihara authored
I initially thought this is a py3-compat bug of passwordmgr._writedebug(), but actually returning (None, str) pair is wrong at all. HTTP authentication would continue with user="None" in that case. Since registering a password of user=None should also be wrong, this patch simply adds early return.
-
Yuya Nishihara authored
Spotted while writing tests for the issue6425. The default value may be None.
-
- Oct 29, 2020
-
-
Dan Villiom Podlaski Christiansen authored
I noticed when pulling with hg-git in a repository that already had the changes, but pulled from another Mercurial repository. This meant that hg-git would re-create exact matches of the changesets, and if they were public, they'd get reverted to drafts. Differential Revision: https://phab.mercurial-scm.org/D9253
-
- Oct 17, 2020
-
-
Yuya Nishihara authored
I'm a bit confused while reading 03690079d7dd, which says "a destination file", but the code loops over matched files.
-
- Oct 13, 2020
-
-
Matt Harbison authored
This excludes the --collapse case because degenerating to p1 is almost certainly as wrong as leaving the old hashes in place. I expect most people to amend the message explicitly when using that. Differential Revision: https://phab.mercurial-scm.org/D9229
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
AFAICT, `cmdutil.rendertemplate()` always returns bytes (never e.g. `None`), so we don't need to fall back to empty (byte-)string. The fallback has been there since the code was added in 11c076786d56 (histedit: add templating support to histedit's rule file generation, 2019-01-29). Differential Revision: https://phab.mercurial-scm.org/D9244
-
- Oct 20, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9233
-
- Oct 19, 2020
-
-
Jörg Sonnenberger authored
The core internals either use revision sets already or can trivially use them. Use the new interface in cg1unpacker.apply to avoid materializing the list of all new nodes as it is normally just a revision range. This avoids about 67 Bytes / changeset on AMD64 in peak RSS. Differential Revision: https://phab.mercurial-scm.org/D9232
-
- Oct 18, 2020
-
-
Jörg Sonnenberger authored
The addgroup() interface currently doesn't allow the caller to keep track of duplicated nodes except by looking at the returned node list. Add an optional second callback for this purpose and change the return type to a boolean. This allows follow-up changes to use more efficient storage for the node list in places that are memory-sensitive. Differential Revision: https://phab.mercurial-scm.org/D9231
-
- Oct 07, 2020
-
-
Pulkit Goyal authored
I am trying to fix a breakage where somehow we end up getting a node of 12 length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems highly unlikely that it can happen unless one of `mctx.readfast().get()` or `ctx.filenode()` is returning a node of 12 length. For safety, I think it's better to add a check to make sure that record which we are parsing is of same length we are expecting otherwise we consider that as invalid record. Differential Revision: https://phab.mercurial-scm.org/D9169
-
- Oct 14, 2020
-
-
Pierre-Yves David authored
For automatic clonebundles generation I need to pass arbitrary large amount of data to the process (eg: common nodes, target nodes). I am updating the `runbgcommand` to allow for this. Previously not stdin input was possible, now, one can provide raw bytes and they will be feed to the command through an unnamed temporary files. Differential Revision: https://phab.mercurial-scm.org/D9212
-
Pierre-Yves David authored
I am about to add more reference to it, so I would rather have it an explicit constant. This allow to unify various call too. Differential Revision: https://phab.mercurial-scm.org/D9209
-
- Oct 15, 2020
-
-
Pierre-Yves David authored
In the process on general clone bundle automatically, we need to make some function available more widely. This is a good opportunity to extract a significant amount of code from `mercurial.exchange` into a new `mercurial.bundlecaches`. This make `mercurial.exchange` move under the 3K line range (hooray…). The module is called `bundlecaches` because I expect it to be eventually useful for more than just clone bundle (like pull bunbles). Differential Revision: https://phab.mercurial-scm.org/D9208
-
- Jul 01, 2020
-
-
Pulkit Goyal authored
Previous patches add a safe mode for sharing repositories which involve sharing of source requirements and config files. In certain situations we might need to add a config to source repository which we does not want to share. For this, we add a `.hg/hgrc-not-shared` which won't be shared. This also adds a `--non-shared` flag to `hg config` command to see the non-shared config. Differential Revision: https://phab.mercurial-scm.org/D8673
-
- Sep 18, 2020
-
-
Pulkit Goyal authored
It seems to me now that there are two steps when config is loaded: 1) on dispatch 2) repository object creation Recent patches added functionality that there can be shares in share-safe mode where config of the source repository is shared with the the shares. However we missed adding logic to read the source config on dispatch. This leads to extensions not being loaded on dispatch and hence extensions command not being recognized. This patch fixes it by reading the shared source config on dispatch. Differential Revision: https://phab.mercurial-scm.org/D9047
-
Pulkit Goyal authored
When we are using share-safe and loading source repository config, we are still not loading the extensions which are enabled in the source repository. This patch demonstrates the bug. Meanwhile it also shows how unreliable `hg debugextensions` is. Differential Revision: https://phab.mercurial-scm.org/D9046
-
- Oct 09, 2020
-
-
Pierre-Yves David authored
But explicitly with the special case early, laying out the various case become simpler. (The initial motivation was to make some future lifetime error simpler). Differential Revision: https://phab.mercurial-scm.org/D9203
-
- Oct 20, 2020
-
-
Jörg Sonnenberger authored
For a large repository, this reduces the number of filelog instances and associated data a lot. For a 1% speed penalty, it reduces peak RSS by 20% for the full NetBSD test repository. Differential Revision: https://phab.mercurial-scm.org/D9235
-
- Oct 14, 2020
-
-
Martin von Zweigbergk authored
I also removed some unnecessary `#if no-changeset` where the `#else` was the same :P Differential Revision: https://phab.mercurial-scm.org/D9204
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
When the config parser raises a ParseError, it uses the line that failed to parse as the error message. It doesn't currently tell the user anything about why it failed to parse. b13b99d39a46 (config: highlight parse error caused by leading spaces (issue3214), 2014-03-16) added a checked based on the error *message* having leading spaces. That has worked fine because only the config parser uses the line itself as error message (I think the revset and fileset parsers use more user-friendly proper messages). It still feels like a hack. Let's make the config parser give a useful message about leading whitespace instead. We should ideally follow up with more useful messages for other parse errors in config files. Differential Revision: https://phab.mercurial-scm.org/D9241
-
Martin von Zweigbergk authored
As with similar previous patches, this is to improve readability. Differential Revision: https://phab.mercurial-scm.org/D9240
-
- Oct 20, 2020
-
-
Martin von Zweigbergk authored
StorageError already provides the same definition. Differential Revision: https://phab.mercurial-scm.org/D9234
-
- Oct 16, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9218
-
- Oct 27, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9255
-
Martin von Zweigbergk authored
This means that the `phabricator.node` and `phabricator.desc` color configs will no longer be respected, but `log.changeset` and `log.desc` will be respected instead. Differential Revision: https://phab.mercurial-scm.org/D9254
-
Martin von Zweigbergk authored
This removes the default template in rebase and switches to a centrally defined template. I've simplified it a bit to avoid the conditional parenthesis. I've also added labels so the different parts can be easily colored. The template is somewhat similar to what we've used internally at Google for a few years. I'm happy to change the template if others have opinions. Should we reuse the `color.log.` names as I have? Differential Revision: https://phab.mercurial-scm.org/D9252
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9251
-
Martin von Zweigbergk authored
This is to prepare for making making the one-line summary customizable. The template ended up pretty complicated because of the conditional output of "(<bookmarks etc>)". Maybe we can simplify the template later. Differential Revision: https://phab.mercurial-scm.org/D9250
-
- Oct 26, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9249
-