<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7233.28"> <TITLE>R: bzr speed</TITLE> </HEAD> <BODY>  See my previous email <A HREF="https://lists.ubuntu.com/archives/bazaar-ng/2006q1/007579.html">https://lists.ubuntu.com/archives/bazaar-ng/2006q1/007579.html</A> the big gain is due to the support for multiple http request per connection Goffredo -----Messaggio originale----- Da: bazaar-ng-bounces@lists.canonical.com per conto di Martin Pool Inviato: mer 08/02/2006 8.23 A: Diwaker Gupta Cc: bazaar-ng@lists.canonical.com; Robert Collins Oggetto: Re: bzr speed On  7 Feb 2006, Diwaker Gupta <diwaker.lists@gmail.com> wrote: > On 2/7/06, Robert Collins <robertc@robertcollins.net> wrote: > I certainly hope so. But cutting down from 1 hr to 1 min seems > somewhat daunting to me. I haven't scraped through the mailing lists > yet, so don't waste your time on this, but _if_ someone wishes, I'd > love to hear about exactly what are the bottlenecks? I mean, this is > an order of magnitude slowdown, and bzr.dev is nowhere as big as say > the kernel tree. Briefly, the main things are:  - Packing information into chunks that can be more easily fetched    across http/sftp (RevFile that robert mentioned)  - Using a more efficient http library (PyCurl)  - Using a "smart server", ie a program running on the server, as    mercurial does.   Not everyone wants to (or is able to) install    a program on their web server, so we want to make bzr as fast    as possible over plain http.  It is harder that way though. -- Martin </BODY> </HTML>