[PATCH 1 of 4] revset: replace "list(repo)" for efficiency on large repository

[Pierre-Yves David]

On Fri, Mar 29, 2013 at 08:27:28PM +0400, Nikolaj Sjujskij wrote:
> Den 2013-03-29 20:16:31 skrev FUJIWARA Katsunori <foozy at lares.dti.ne.jp>:
> 
> ># HG changeset patch
> ># User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> ># Date 1364573132 -32400
> ># Node ID 4cf0465cd64ff196ad83ec2d10b6e13ed89c2913
> ># Parent  fabbaa250977ad337a36b1c4cece22da94adfe4b
> >revset: replace "list(repo)" for efficiency on large repository
> >
> >Before this patch, "list(repo)" is used as "subset" to mean "whole
> >revisions in repository".  This creation of list is not efficient in
> >points below:
> >
> >   - this causes immediate creation of list containing integers
> >     corresponding to revisions in repository:
> >
> >     repository may have many revisions in itself
> >
> >  - "subset" contents may not be used in some cases:
> >
> >    "stringset()" omits examination of subset contents, if "len(repo)
> >    == len(subset)", for example
> >
> >  - examination of "x in subset" may scans list fully
> >...
> >  - "tip::tip":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 888)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1125)
> >
> >  - "ancestor(1)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 2105)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 3847)
> >
> >  - "ancestors(1)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 861)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1055)
> >
> >  - "tip and branch(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1887)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 3290)
> >
> >  - "tip and children(39998)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 2026)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 3650)
> >
> >  - "descendants(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 869)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1085)
> >
> >  - "tip and destination(39998)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1989)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 3525)
> >
> >  - "limit(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 894)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1140)
> >
> >  - "last(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 890)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1142)
> >
> >  - "max(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1381)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1969)
> >
> >  - "min(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1378)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1958)
> >
> >  - "39998 and origin(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 2001)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 3519)
> >
> >  - "p1(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 880)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1079)
> >
> >  - "p2(tip)":
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 877)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1082)
> >
> >  - "parents(tip)"
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 871)
> >    ! wall 0.000000 comb 0.000000 user 0.000000 sys 0.000000 (best
> >of 1063)
> 
>  That's one of the least persuasive benchmarks I've ever seen :)
> As far as I can see, your patch makes all the operations at least
> three times slower (some of them even five times!)

My HC cluster says the new version is NaN time better than the old one.
This mean my results is different than yours … and than mine.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130329/40f274c0/attachment.pgp>