Merge lp://staging/~jameinel/loggerhead/incremental_import into lp://staging/loggerhead
| Status: | Merged |
|---|---|
| Approved by: | Michael Hudson-Doyle |
| Approved revision: | 447 |
| Merged at revision: | 447 |
| Proposed branch: | lp://staging/~jameinel/loggerhead/incremental_import |
| Merge into: | lp://staging/loggerhead |
| Diff against target: |
18 lines (+2/-2) 1 file modified
loggerhead/history_db.py (+2/-2) |
| To merge this branch: | bzr merge lp://staging/~jameinel/loggerhead/incremental_import |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Hudson-Doyle | Approve | ||
|
Review via email:
|
|||
Commit message
When creating the history.db cache file, do a non-incremental import.
Description of the change
This reactivates a heuristic for the history-db import logic.
This makes first-time import a lot faster.
The idea is:
a) Most of the time, the cache is already populated, so you don't want to load the whole ancestry of a branch. Just to only import the last few revisions.
b) However, if you are creating the database file, you *know* that you have to import the whole ancestry.
c) bzrlib has special apis to make "give me the whole ancestry" faster. It is something we avoid doing, but when you need it, you have it. Those apis also use a Pyrex extension to compute a lot of the data that we recompute on-the-fly in the incremental case.
In the case of doing 'bzr serve --http' on a Launchpad tree, it drops the time for the first page view from about 19s down to about 11-12s (the target is the ~6-7s that the non-history-db code took).
| Michael Hudson-Doyle (mwhudson) | # |
