From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Surely 'bzr update' shouldn't be this slow? Date: Thu, 07 Jan 2010 16:17:20 +0100 Message-ID: <87ocl6c5bz.fsf@telefonica.net> References: <20100103174743.GB1653@muc.de> <87bphbhxxt.fsf@telefonica.net> <20100106131039.GB2447@muc.de> <4B448FF5.5060900@gnu.org> <87hbqze39u.fsf@telefonica.net> <20100107134011.GA2381@muc.de> <87wrzuc93h.fsf@telefonica.net> <20100107145216.GB2381@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1262877549 27477 80.91.229.12 (7 Jan 2010 15:19:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2010 15:19:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 07 16:19:02 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NSu8Y-0003D6-Es for ged-emacs-devel@m.gmane.org; Thu, 07 Jan 2010 16:18:59 +0100 Original-Received: from localhost ([127.0.0.1]:45973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSu8Y-0008Hf-GP for ged-emacs-devel@m.gmane.org; Thu, 07 Jan 2010 10:18:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSu7a-0007hl-Kx for emacs-devel@gnu.org; Thu, 07 Jan 2010 10:17:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSu7V-0007fc-Pv for emacs-devel@gnu.org; Thu, 07 Jan 2010 10:17:57 -0500 Original-Received: from [199.232.76.173] (port=59129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSu7V-0007fV-J6 for emacs-devel@gnu.org; Thu, 07 Jan 2010 10:17:53 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:54748) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSu7V-0003Px-0U for emacs-devel@gnu.org; Thu, 07 Jan 2010 10:17:53 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NSu7O-0002al-MH for emacs-devel@gnu.org; Thu, 07 Jan 2010 16:17:46 +0100 Original-Received: from 217.red-88-24-214.staticip.rima-tde.net ([88.24.214.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 16:17:46 +0100 Original-Received: from ofv by 217.red-88-24-214.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Jan 2010 16:17:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 217.red-88-24-214.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:9mkqz0xhokg7hsaSRckBwRR8MGw= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119585 Archived-At: Alan Mackenzie 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