Merge lp://staging/~maxb/loggerhead/jameinel-page_loading into lp://staging/loggerhead
Proposed by
Max Bowsher
| Status: | Merged |
|---|---|
| Merged at revision: | 439 |
| Proposed branch: | lp://staging/~maxb/loggerhead/jameinel-page_loading |
| Merge into: | lp://staging/loggerhead |
| Diff against target: |
91 lines (+41/-7) 2 files modified
loggerhead/controllers/changelog_ui.py (+2/-1) loggerhead/history.py (+39/-6) |
| To merge this branch: | bzr merge lp://staging/~maxb/loggerhead/jameinel-page_loading |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Loggerhead Team | Pending | ||
|
Review via email:
|
|||
Commit message
Change the history load so that we only request the recent revs.
Rather than loading the whole mainline and then discarding all but the most recent.
Can save 2-400ms on emacs/trunk
Description of the change
This is a simple re-push and re-propose of lp:~jameinel/loggerhead/page_loading, to track that this piece of work de-merged in the switching around of trunk exists as an independently re-landable entity.
To post a comment you must log in.
Revision history for this message
| John A Meinel (jameinel) wrote | # |
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/10/2011 03:18 PM, Max Bowsher wrote:
> Max Bowsher has proposed merging lp:~maxb/loggerhead/jameinel-page_loading into lp:loggerhead.
>
> Requested reviews:
> Loggerhead-team (loggerhead-team)
>
> For more details, see:
> https:/
>
> This is a simple re-push and re-propose of lp:~jameinel/loggerhead/page_loading, to track that this piece of work de-merged in the switching around of trunk exists as an independently re-landable entity.
This one is a little bit more clumsy, and should probably be written to
use tests.
For context, this matters the most once we have history-db, though I
think it is still a performance win without it.
The way the 'changes' page works, it wants to show (say) 20 revisions.
But it also wants to be able to give a link to the next N revisions. To
do so, it needs to know the revision_ids and some other information.
The way the code used to work, was it would generate the entire history,
and then poke at the 20+N revision to find its URL. Note that for emacs,
"entire history" is 100,000 revisions, so reducing the information
needed to 20+N is still a decent win.
I do find the way I implemented it clumsy, but it worked.
I think the biggest win, though, was once you have history-db, since
this is one of the whole-ancestry requests that had to go.
Again, approve/I can work on this a bit. Right now I'm focused on some
of the critical bugs we hit today. But maybe soon.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk1
vmAAoLutuwiovTZ
=b20y
-----END PGP SIGNATURE-----