locking repository makes no difference to speed of repeated get_revision calls
Bug #248604 reported by
Michael Hudson-Doyle
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Invalid
|
Medium
|
Unassigned | ||
Bug Description
While we all know that calling get_revisions once is better than calling get_revision a bunch of times, it seems that there is still a serious regression in performance of the latter between 1.5 and current bzr.dev (not far off 1.6 at the time of writing).
Basically, it seems that given a branch b and its revision_history rh. "map(b.
Revision history for this message
| John A Meinel (jameinel) wrote | #1 |
| Changed in bzr: | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
Revision history for this message
| Michael Hudson-Doyle (mwhudson) wrote | #2 |
| Changed in bzr: | |
| status: | Triaged → Invalid |
Revision history for this message
| Robert Collins (lifeless) wrote Re: [Bug 248604] Re: locking repository makes no difference to speed of repeated get_revision calls | #3 |
To post a comment you must log in.
Is this on a Knit format repository, or a Pack format repository?
The dev branch since about 1.3 has removed the Transaction cache for Knit repositories. We've been continually restoring it for each release (1.4, 1.5).
Out of curiosity, does this mean b.repository.
I don't know whether we plan to restore the transaction cache yet again for the 1.6 release. Knits are sort of fading as Robert brings in more patches to align the internals with pack style repositories.
My personal feeling is that the cache should be kept for Knit repos. I believe Robert wanted it out to help force developers to move apis over to better ones (like using get_revisions() instead of looping over get_revision). Though as most of us are now solely on pack repos, nobody really realizes how much performance on Knit repos has regressed. So that part of the experiment is a bit of a failure.