Speedup with history-db
John Arbash Meinel
john at arbash-meinel.com
Tue May 31 09:47:55 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
>> Counting the whole revision table is stupid. I just committed what
>> should be a fix for that (revno 135).
>
> Thanks. This slashed the time significantly, but bzr consistently
> says it imports 4 revisions each time I do a "bzr up" with no new
> revisions available in the remote repo:
>
> 9.360 fetch up to rev {rgm at gnu.org-20110527071815-pnm36i0e38mb8wte}
> 11.766 history_db post-change-hook took 0.246s (0.002s to get_config, 0.096s to init, 0.148s to import)
> 11.766 Stats:
> {'num_search_tips': 0,
> 'step mainline': 1,
> 'step mainline added': 4,
> 'step mainline cache missed': 1,
> 'step mainline initial': 1}
> [ 3688] 2011-05-27 18:06:55.062 INFO: Tree is up to date at revision 104384 of branch bzr+ssh://eliz@bzr.savannah.gnu.org/emacs/trunk
>
> It looks like something else is at work here.
1) That isn't actually imported, that is how much data we read from the
db to do our work. I should probably clarify the strings, but I'm not
really sure how to do so.
2) rev 139 has a few fixes
a) I used to explicitly check that a tip wasn't already imported,
apparently that got removed, but I brought it back.
b) handle the 'bzr up' case when nothing changes. Bazaar fires the
"post-branch-tip-changed" hook, even though old_revid ==
new_revid. I added the shortcut so we don't even have to parse
config files, etc. It should be an uncommon case, but we might as
well have a no-op be a no-op.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3kuUsACgkQJdeBCYSNAAOWmgCfeF/IziYFwugzUYgn6j6Gjq7+
VHUAoIqLgZG+WQBxD3DSqeVZDugHR1E1
=6OdM
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list