8b90367c4cf3892fd4bd092a320f77134beedc85: tests: make test-verify-repo-operations.py not run by default
Martin von Zweigbergk <martinvonz@google.com> - Fri, 11 Mar 2016 11:44:03 -0800 - rev 30801
Push 208 by gszorc@mozilla.com at Sat, 19 Mar 2016 01:42:47 +0000
tests: make test-verify-repo-operations.py not run by default test-verify-repo-operations.py currently starts way too late and extends the running time with -j50 on my machine from around 3:48 min to 6:30 min. We could of course make it run earlier, but the test case seems unlikely to find bugs not covered by other tests, so let's mark it "slow" instead. I think this type of test is better suited to running separately in a long-running job.
d09be0b8a3c6844ebbba034516995e0115d0a8dc: ui: log devel warnings
timeless <timeless@mozdev.org> - Fri, 29 Jan 2016 14:37:16 +0000 - rev 30800
Push 208 by gszorc@mozilla.com at Sat, 19 Mar 2016 01:42:47 +0000
ui: log devel warnings
906fece80cfad1328c0f6ce0630a88c2dcccfb5d: util: refactor getstackframes
timeless <timeless@mozdev.org> - Fri, 11 Mar 2016 17:22:04 +0000 - rev 30799
Push 208 by gszorc@mozilla.com at Sat, 19 Mar 2016 01:42:47 +0000
util: refactor getstackframes
b592564a803c0430183ac7784756a01cdbdb14d5: util: reword debugstacktrace comment
timeless <timeless@mozdev.org> - Fri, 11 Mar 2016 16:50:14 +0000 - rev 30798
Push 208 by gszorc@mozilla.com at Sat, 19 Mar 2016 01:42:47 +0000
util: reword debugstacktrace comment
0f02cccc4f7185c5e5095a8804a65f87865c2d14: exchange: add pushfinish event draft
Gregory Szorc <gregory.szorc@gmail.com> - Mon, 18 Aug 2014 22:20:15 -0700 - rev 30788
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
exchange: add pushfinish event The pushfinish event provides an extensibility point to see what the final result of a push was. It also allows extensions to change the result code of a push. This commit rounds out events for pushing, having established code injection points in nearly every place extensions may want them.
4a95e8674fccd3e1624f9b48526da5151c967ace: exchange: add pushafterdatasent event draft
Gregory Szorc <gregory.szorc@gmail.com> - Mon, 18 Aug 2014 22:07:47 -0700 - rev 30787
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
exchange: add pushafterdatasent event Extensions may wish to perform functionality after a push has transferred data but while a lock on the local repo is still held. The pushafterdatasent event facilities that.
c7abc9a2eca14dec4ad95a392d67bc9fbdb7c792: exchange: add pushafterdiscovery event draft
Gregory Szorc <gregory.szorc@gmail.com> - Mon, 18 Aug 2014 22:03:04 -0700 - rev 30786
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
exchange: add pushafterdiscovery event Extensions may wish to inject code after discovery. For example, they may wish to ban certain changesets or changesets with certain content from being pushed. The "preoutgoing" hook facilitates this today. However, it doesn't have access to the rich pushoperation object because of backwards compatibility. The pushafterdiscovery event gives extensions a more robust injection point.
20a352d38d29c8b57ff54d865efa7c28286b46f3: exchange: add pushbegin event draft
Gregory Szorc <gregory.szorc@gmail.com> - Mon, 18 Aug 2014 21:52:23 -0700 - rev 30785
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
exchange: add pushbegin event Extensions may wish to influence what is being done by a push operation. To facilitate this, we establish the "pushbegin" event, which fires immediately after a pushoperation is created and gives extensions the ability to inspect and/or change the pushoperation before any additional action is taken.
2868576761228e870049aa2609f25966ed938b01: localrepo: add events support to localrepository draft
Gregory Szorc <gregory.szorc@gmail.com> - Mon, 18 Aug 2014 21:44:47 -0700 - rev 30784
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
localrepo: add events support to localrepository The first logical place to add events support is the localrepository class. This patch adds a skeleton for events there.
d2e124966a43d2b0498dc39d15d3b3c32d6e01ee: util: add event handling mechanism draft
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 28 Sep 2014 12:43:27 -0700 - rev 30783
Push 206 by gszorc@mozilla.com at Mon, 14 Mar 2016 00:50:31 +0000
util: add event handling mechanism The patch adds a generic event handling mechanism to Mercurial. From a high level, you create a class with methods corresponding to event names. You can then register functions/callbacks against events that get called when that event fires. As will be demonstrated in subsequent patches, event handling can be considered an internal hooks mechanism and will provide a better alternative to wrapping or monkeypatching. The intent of the events system is to give extensions a more well-defined point for code insertion. Currently, extension authors have a limited set of hooks and a giant pile of functions to choose from. Hooks often don't satisfy your requirements and you need to dig through a pile of code to find an appropriate function to intercept. Then you need to replace/monkeypatch this function. This is an inexact science and is difficult to do robustly. The result are extensions that do live dangerously. Events will provide a better mechanism for code insertion. Events solve the discovery problem by providing a well-defined (like hooks) set of places for supported code insertion. Events are also easier to code, as extension authors don't need to worry about monkeypatching: just write a function and register it. Events have another advantage over monkeypatching in that they can be instance specific. Monkeypatching often results in changing symbols on modules or class types as opposed to individual methods on individual object instances. Oftentimes you only want to apply customization to a single instance of an object if that object meets certain criteria. In the current world, you often have to globally replace and filter out invocations at call time that aren't appropriate. This is prone to failure due to monkeypatched functions not taking all uses into consideration. Furthermore, monkeypatching can be difficult for module-level symbols. If a module-level function is imported by another module (from foo import bar), you'll need to monkeypatch that imported symbol as well. It is time consuming for module authors to keep up with Mercurial changes and to ensure that imported uses are always monkeypatched. Again, events solve this challenge.
66bd14c189197635a1f532c00b1034952b6058f7: filemerge: exclude some markup languages from conflict marker detection draft
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 31 Aug 2014 09:40:17 +0200 - rev 30768
Push 204 by gszorc@mozilla.com at Sun, 13 Mar 2016 22:51:09 +0000
filemerge: exclude some markup languages from conflict marker detection Detection of conflict markers looks for the '=======' string, which may occur in markup languages such as markdown and restructured text. We omit this part of conflict marker detection for these files.
1af8972249c6e4ae7fd8618b1fb18b68f6fe5744: resolve: print a warning when marking a file with conflict markers draft
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 13 Mar 2016 15:46:03 -0700 - rev 30767
Push 204 by gszorc@mozilla.com at Sun, 13 Mar 2016 22:51:09 +0000
resolve: print a warning when marking a file with conflict markers If you are using internal:merge or any mergetool that inserts conflict markers and use `hg resolve -m`, there's a chance you may accidentally mark a file with conflict markers as resolved. This is almost always unintended. This patch adds a warning so fewer people will shoot themselves with this footgun.
733759a015c950cf12877bbced519b92d7066b02: filemerge: extract conflict marker searching into its own function draft
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 13 Mar 2016 15:44:57 -0700 - rev 30766
Push 204 by gszorc@mozilla.com at Sun, 13 Mar 2016 22:51:09 +0000
filemerge: extract conflict marker searching into its own function
70c2f8a982766b512e9d7f41f2d93fdb92f5481f: changelog: avoid slicing raw data until needed
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 15:40:20 -0800 - rev 30730
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: avoid slicing raw data until needed Before, we were slicing the original raw text and storing individual variables with values corresponding to each field. This is avoidable overhead. With this patch, we store the offsets of the fields at construction time and perform the slice when a property is accessed. This appears to show a very marginal performance win on its own and the gains are so small as to not be worth reporting. However, this patch marks the end of our parsing refactor, so it is worth reporting the gains from the entire series: author(mpm) 0.896565 0.795987 89% desc(bug) 0.887169 0.803438 90% date(2015) 0.878797 0.773961 88% extra(rebase_source) 0.865446 0.761603 88% author(mpm) or author(greg) 1.801832 1.576025 87% author(mpm) or desc(bug) 1.812438 1.593335 88% date(2015) or branch(default) 0.968276 0.875270 90% author(mpm) or desc(bug) or date(2015) or extra(rebase_source) 3.656193 3.183104 87% Pretty consistent speed-up across the board for any revset accessing changelog revision data. Not bad! It's also worth noting that PyPy appears to experience a similar to marginally greater speed-up as well! According to statprof, revsets accessing changelog revision data are now clearly dominated by zlib decompression (16-17% of execution time). Surprisingly, it appears the most expensive part of revision parsing are the various text.index() calls to search for newlines! These appear to cumulatively add up to 5+% of execution time. I reckon implementing the parsing in C would make things marginally faster. If accessing larger strings (such as the commit message), encoding.tolocal() is the most expensive procedure outside of decompression.
63653147e9bb26550cbe46d5a1bdf961471af0e5: changelog: parse description last
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 13:13:54 -0800 - rev 30729
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: parse description last Before, we first searched for the double newline as the first step in the parse then moved to the front of the string and worked our way to the back again. This made sense when we were splitting the raw text on the double newline. But in our new newline scanning based approach, this feels awkward. This patch updates the parsing logic to parse the text linearly and deal with the description field last. Because we're avoiding an extra string scan, revsets appear to demonstrate a very slight performance win. But the percentage change is marginal, so the numbers aren't worth reporting.
7796473c11b3b0c132bea567a4660626cb57fdb2: changelog: lazily parse files
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 14:31:06 -0800 - rev 30728
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: lazily parse files More of the same. Again, modest revset performance wins: author(mpm) 0.896565 0.822961 0.805156 desc(bug) 0.887169 0.847054 0.798101 date(2015) 0.878797 0.811613 0.786689 extra(rebase_source) 0.865446 0.797756 0.777408 author(mpm) or author(greg) 1.801832 1.668172 1.626547 author(mpm) or desc(bug) 1.812438 1.677608 1.613941 date(2015) or branch(default) 0.968276 0.896032 0.869017
837f1c437d5832e8efe4b7211a7ea96d1cf3e047: changelog: lazily parse date/extra field
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 14:30:25 -0800 - rev 30727
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: lazily parse date/extra field This is probably the most complicated patch in the parsing refactor. Because the date and extras are encoded in the same field, we stuff the entire field into a dedicated variable and add a property for accessing the sub-components of each. There is some duplicated code here. But the code is relatively simple, so it shouldn't be a big deal. We see revset performance wins across the board: author(mpm) 0.896565 0.876713 0.822961 desc(bug) 0.887169 0.895514 0.847054 date(2015) 0.878797 0.820987 0.811613 extra(rebase_source) 0.865446 0.823811 0.797756 author(mpm) or author(greg) 1.801832 1.784160 1.668172 author(mpm) or desc(bug) 1.812438 1.822756 1.677608 date(2015) or branch(default) 0.968276 0.910981 0.896032 author(mpm) or desc(bug) or date(2015) or extra(rebase_source) 3.656193 3.516788 3.265024 We see a speed-up on revsets accessing date and extras because the new parsing code only parses what you access. Even though they are stored the same text field, we avoid parsing dates when accessing extras and vice-versa. But strangely revsets accessing both date and extras appeared to speed up as well! I'm not sure if this is due to refactoring the parsing code or due to an optimization in revsets. You can't argue with the results!
f57f7500a095fe4dfb31a84b4c39dbe606271955: changelog: lazily parse user
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 14:29:46 -0800 - rev 30726
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: lazily parse user Same strategy as before. Revsets not accessing the user demonstrate a slight performance win: desc(bug) 0.887169 0.910400 0.895514 date(2015) 0.878797 0.870697 0.820987 extra(rebase_source) 0.865446 0.841644 0.823811 date(2015) or branch(default) 0.968276 0.945792 0.910981
959eadae589a2fe7fec205180175434faae13a70: changelog: lazily parse manifest node
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 14:29:13 -0800 - rev 30725
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: lazily parse manifest node Like the description, we store the raw bytes and convert from hex on access. This patch also marks the beginning of our new parsing method, which is based on newline offsets and doesn't rely on str.split(). Many revsets showed a performance improvement: author(mpm) 0.896565 0.869085 0.868598 desc(bug) 0.887169 0.928164 0.910400 extra(rebase_source) 0.865446 0.871500 0.841644 author(mpm) or author(greg) 1.801832 1.791589 1.731503 author(mpm) or desc(bug) 1.812438 1.851003 1.798764 date(2015) or branch(default) 0.968276 0.974027 0.945792
8939a95064f11573dd274e511937837ff7f6e25b: changelog: lazily parse description
Gregory Szorc <gregory.szorc@gmail.com> - Sun, 06 Mar 2016 14:28:46 -0800 - rev 30724
Push 200 by gszorc@mozilla.com at Sat, 12 Mar 2016 00:54:44 +0000
changelog: lazily parse description Before, the description field was converted to a localstr at parse time. With this patch, we store the raw description and convert to a localstr when it is first accessed. We see a revset speedup for revsets that don't access the description: author(mpm) 0.896565 0.914234 0.869085 date(2015) 0.878797 0.891980 0.862525 extra(rebase_source) 0.865446 0.912514 0.871500 author(mpm) or author(greg) 1.801832 1.860402 1.791589 date(2015) or branch(default) 0.968276 0.994673 0.974027 author(mpm) or desc(bug) or date(2015) or extra(rebase_source) 3.656193 3.721032 3.643593 As you can see, most of these revsets are already faster than from before this refactoring: we have already offset the performance loss from the introduction of the new class representing parsed changelog entries!
(0) -30000 -10000 -1000 -100 +20 +50 +100 +300 +1000 +10000 tip