[PATCH 01 of 15] hgext: `speedy` - the history query accelerator

[Tomasz Kłeczek]

  Here are the updated results for the local/remote mode  (I am also going
to include them in the commit message).

   hg log somedir -l1
    -> 1.8 sec local, 0.8 sec remote

  hg log --rev "author(someuser)" -l1
    -> 1.4 sec local, 0.2 sec remote

  hg log --rev "date(10/1/2012)" -l1
    -> 1.7 sec local, 0.8 sec remote

  hg log "relglob:**.html" -l1
    -> 2.1 sec local, 1.3 sec remote

  hg log . -l1
    -> 5.7 sec local, 10.6 sec remote


On Thu, Dec 13, 2012 at 12:07 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> On Tue, Dec 11, 2012 at 10:38:16AM -0800, Tomasz Kleczek wrote:
> > # HG changeset patch
> > # User Tomasz Kleczek <tkleczek at fb.com>
> > # Date 1355250659 28800
> > # Branch stable
> > # Node ID 13c6bcb8dd900dc7dbf5e3da9ef68d56fed250b3
> > # Parent  8973e7dd92d5afdeb82e91d5b66934d53a74e8da
> > hgext: `speedy` - the history query accelerator
> >
> > This is the first in a series of patches that address the problem
> > of hg log being slow on a big repo in most cases.
> >
> >
> > Many history queries have performance linear in the number of commits
> > or even worse - the size of manifest.
> >
> > As a result almost every hg log query with non-trivial rev range or
> > with directory specified is painfully slow on big repositories
> > and its poor performance doesn't depend on actual output size.
> >
> > Here are some frequently used commands that just print a handful of
> > log messages:
> >   * hg log dir_with_few_commits
> >   * hg log --rev "user(MyLazyFriend)"
> >
> > They may take more then 30 secs on a big repo (with couple hundred
> > thousands of commits).
> >
> > This extension addresses this problem by introducing a server component
> > that maintains indices over the history and uses them to respond to
> queries
> > in an efficient manner.
> >
> > What is going on:
> >
> > * the client component forwards certain history queries to the server
> >   and waits for a response
> > * it takes into account that its history may have diverged from
> >   the server's, and still gives correct answers
> > * if the server doesn't respond fast enough or crashes, the client falls
> >   back to computing the answer locally using normal code path
> > * extension setup time is neglible and there is no overhead for queries
> >   that cannot be accelerated by the server
> >
> > The server can be run:
> > * locally in the same process as client or
>
> Could you includes some numbers about this local version ?
>
> It sound like it could have interresting application within graphical
> history
> viewer like TortoiseHG or hgview. Those qre long lived process that can
> absorbs
> the setup time and benefit from the speed up.
>
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121213/9d45579c/attachment.html>