manifestmerge: fix order in which manifests are fetched If the manifest of an earlier revision on the same delta chain is read before that of a later revision, the revlog remembers that we parsed the earlier revision and continues applying deltas from there onwards. If manifests are parsed the other way round, we have to start over from the fulltext. For a fresh clone of mozilla-central, updating from 29dd80c95b7d to its parent aab96936a177 requires approximately 400 fewer zlib.decompress calls, which results in a speedup from 1.10 seconds to 1.05.

merge: run _forgetremoved after manifestmerge _forgetremoved can trigger manifest construction, but we only want it to happen after manifestmerge, so that our attempt to read the manifests in the right order in an upcoming patch actually works.

dirstate: disable gc while parsing the dirstate This prevents a performance regression an upcoming patch would otherwise introduce because it indirectly delays parsing the dirstate a bit.