Re: [Monotone-devel] Unnecessary performance hit on push?

[Marcel van der Boom]

On 29 sep 2005, at 5:20, Nathaniel Smith wrote:
> I don't have time to try this out ATM; anyone interested in seeing if
> it makes a difference?

On average it does make around 20-30% difference for us on pushing / 
pulling. It differs a bit on the operation involved and the database  
in use.

However, at least on osx, i see some rather weird behaviour:

Two consecutive pulls :
address@hidden:~/dev/xar/mtn/com.xaraya.sandbox$ time mt.dev pull  
mt.xaraya.com:15000  com.xaraya.sandbox
monotone: connecting to mt.xaraya.com:15000
monotone: finding items to synchronize:
monotone: Found 123 branches <-- it spends all its time just after this
monotone: Branch com.xaraya.sandbox has 77 revs to consider
monotone:   certs |    keys | revisions
monotone:     390 |       2 |        88
monotone: bytes in | bytes out | certs in | revs in | revs written
monotone:      219 |      1118 |        0 |       0 |            0
monotone: read from fd 5 (peer mt.xaraya.com:15000) closed OK after  
goodbye

real    6m54.444s (!!!)
user    0m6.355s
sys     0m11.660s
address@hidden:~/dev/xar/mtn/com.xaraya.sandbox$ time mt.dev pull  
mt.xaraya.com:15000  com.xaraya.sandbox
monotone: connecting to mt.xaraya.com:15000
monotone: finding items to synchronize:
monotone: Found 123 branches
monotone: Branch com.xaraya.sandbox has 77 revs to consider
monotone:   certs |    keys | revisions
monotone:     390 |       2 |        88
monotone: bytes in | bytes out | certs in | revs in | revs written
monotone:      242 |      1095 |        0 |       0 |            0
monotone: write on fd 5 (peer mt.xaraya.com:15000) closed OK after  
goodbye

real    0m15.463s
user    0m4.479s
sys     0m2.342s

From nearly 7minutes to 15 secs?  The extra output corresponds with  
this netsync.cc fragment:

around line: 3727:
  {
    // Get our branches
    vector<string> names;
    get_branches(app, names);
    P(F("Found %d branches") % names.size());
    for (size_t i = 0; i < names.size(); ++i)
      {
        if(branchnames.find(names[i]) != branchnames.end())
          {
            // branch matches, get its certs
            vector< revision<cert> > certs;
            base64<cert_value> encoded_name;
            encode_base64(cert_value(names[i]),encoded_name);
            app.db.get_revision_certs(branch_cert_name,  
encoded_name, certs);
            P(F("Branch %s has %d revs to consider") % names[i] %  
certs.size());
            for (size_t j = 0; j < certs.size(); ++j)
              {
                insert_with_parents(revision_id(idx(certs,j).inner 
().ident),
                                    revision_ids, app,  
revisions_ticker);
              }
          }
      }
  }

What on earth is the system doing during the 7 mins?  After the  
"Found 123 branches" theoretically it loops 122 times with 1 find  
statement to execute in each loop?
The second and later runs stay around 12-15 secs which seems normal.  
The long delay between the "Found 123 branches" and the "Branch has  
77 revs to consider" is then gone too.

Is monotone just waiting on the OS? Why?

/me clueless


--
Marcel van der Boom
HS-Development BV               --   http://www.hsdev.com
So! webapplicatie framework  --   http://make-it-so.info

smime.p7s
Description: S/MIME cryptographic signature