all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Surely 'bzr update' shouldn't be this slow?
Date: Thu, 07 Jan 2010 16:17:20 +0100	[thread overview]
Message-ID: <87ocl6c5bz.fsf@telefonica.net> (raw)
In-Reply-To: 20100107145216.GB2381@muc.de

Alan Mackenzie <acm@muc.de> writes:

[snip]

>> > Why does Bazaar need to "process" this data?  It's essentially doing
>> > copying, with some accompanying administrivia.
>
>> It is not copying, and in that case it can't simply copy the data. A
>> shared repository contains data from all the branches it encloses. When
>> you branch from it, only the data that belongs to the branch you want
>> must be transferred.
>
> It IS copying, conceptually - the content of the branched repository
> contains a portion of the original branch, and nothing else.  So it has
> to do a bit of filtering on the files' logs.  There are ~2000 files in
> Emacs, and that copying/filtering took 39 minutes, about 2300 seconds.
> It's taking over a second per file (at ~100% CPU usage).  A second is
> about how long my PC takes to compile each C file in .../emacs/src.

Things are not so simple. Please note that bzr stores almost 100,000
revisions of Emacs development in a bit more that 200 MB. And each
revision is related to other revisions and that relations needs
traversing. It is obvious that the storage system is far from trivial,
so any complexity assumption based on concepts like files or chunks of
bytes are, very likely, wrong.

>> Yup, that was recently discussed here. It was an exceptional case (I
>> hope).
>
> There have been, perhaps, ~100 files updated since I first downloaded the
> repository last Friday.  For each changed file, bzr transferred ~2Mb
> between my PC and savannah.  Why?  This is ludicrous.
>
> Hopefully it was an exceptional case, but I'd not changed my .../trunk at
> all since downloading it, so anything exceptional was at the savannah
> end.
>
> I'm about to fix a bug which will involve ~100 bytes change to a C file
> and ~200 bytes log message and ChangeLog addition.  How much will the bzr
> commit operation transfer?  Hopefully, several kilobytes, no more.

When bzr communicates with upstream by the http or sftp protocols, it
needs to read or write lots of data because the needed information is
scattered all over the repository files.

In theory, installing the Bazaar smart server in Savannah should fix
those problems.

> Any chance you could point out that other thread to me?

The subthread starts here:

http://article.gmane.org/gmane.emacs.devel/119410

>> Apart from the 200MB download, do you think that bzr is too slow on your
>> daily Emacs work? Which operations are too slow for you?
>
> Yes, bzr is too slow for me.  My first checkout took, perhaps, an hour
> and a half, but I can cope with that.  'bzr branch' (to a random place)
> took 40 minutes.  'bzr branch' to the Right Place took a few seconds, and
> this is the only bzr thing I've done so far which has been reasonable.
> 'bzr update' took 23 minutes, and this is the killer, the operation which
> will make Emacs development such a frustrating, miserable experience; on
> CVS, it would have been faster on my 33MHz 486 with 33kbaud modem.

If the exceptionally long time that it took for certain update is the
biggest problem you found so far, there is no reason to worry. Because
it is not usual (except for that case, bzr needs less than 3 minutes for
updating on my netbook) and because if it becomes too frequent people
here will force the Savannah maintainers to install the smart server.

[snip]

-- 
Óscar





  parent reply	other threads:[~2010-01-07 15:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-03 17:47 Surely 'bzr branch' shouldn't be this slow? Alan Mackenzie
2010-01-03 17:59 ` Óscar Fuentes
2010-01-06 13:10   ` Alan Mackenzie
2010-01-06 13:28     ` Jason Rumney
2010-01-06 14:06       ` Óscar Fuentes
2010-01-06 18:23         ` Eli Zaretskii
2010-01-06 20:21           ` Stefan Monnier
2010-01-07  7:44           ` Yavor Doganov
2010-01-07  8:37             ` Lennart Borgman
2010-01-07  9:31               ` Juanma Barranquero
2010-01-07 19:18               ` Stephen Berman
2010-01-07 19:54               ` Eli Zaretskii
2010-01-07 20:09                 ` Lennart Borgman
2010-01-07 21:48                   ` Jason Earl
2010-01-07 23:48                     ` Lennart Borgman
2010-01-08  2:07                       ` Jason Earl
2010-01-08  7:10                         ` Lennart Borgman
2010-01-08  8:13                   ` Eli Zaretskii
2010-01-07 14:46             ` Stefan Monnier
2010-01-07 17:05               ` Yavor Doganov
2010-01-07 19:43                 ` Stefan Monnier
2010-01-07 19:46                   ` Lennart Borgman
2010-01-07 20:26                     ` Thrashing [was: Surely 'bzr branch' shouldn't be this slow?] Stephen J. Turnbull
2010-01-07 20:20                       ` Lennart Borgman
2010-01-07 13:40         ` Surely 'bzr update' shouldn't be this slow? [was: branch] Alan Mackenzie
2010-01-07 13:56           ` Surely 'bzr update' shouldn't be this slow? Óscar Fuentes
2010-01-07 14:03             ` Lennart Borgman
2010-01-07 15:18               ` Jan Djärv
2010-01-07 14:52             ` Alan Mackenzie
2010-01-07 15:00               ` Juanma Barranquero
2010-01-07 15:17                 ` Karl Fogel
2010-01-07 17:51                   ` Glenn Morris
2010-01-07 20:48                     ` Karl Fogel
2010-01-07 21:21                       ` Glenn Morris
2010-01-08  8:48                       ` Eli Zaretskii
2010-01-07 15:17               ` Óscar Fuentes [this message]
2010-01-07 17:54               ` Stephen J. Turnbull
2010-01-07 15:06           ` Stefan Monnier
2010-01-06 14:37     ` Surely 'bzr branch' " Stefan Monnier
2010-01-07  5:00     ` Karl Fogel
  -- strict thread matches above, loose matches on Subject: below --
2010-01-07 23:29 Surely 'bzr update' " grischka
2010-01-08  5:57 ` Stephen J. Turnbull
2010-01-08 17:49   ` grischka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ocl6c5bz.fsf@telefonica.net \
    --to=ofv@wanadoo.es \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.