From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9e81fa53486a4934 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!216.196.118.149.MISMATCH!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!uio.no!fi.sn.net!newsfeed2.tdcnet.fi!news.song.fi!not-for-mail Date: Mon, 02 Aug 2010 21:01:13 +0300 From: Tero Koskinen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: What is your preferred VCS? References: <24890919-000d-4b75-8556-0585e8a2f59d@g21g2000prn.googlegroups.com> <87k4odxcuz.fsf@ludovic-brenta.org> <4c52f115$0$6893$9b4e6d93@newsspool2.arcor-online.net> <4c530d7a$0$10185$ba4acef3@reader.news.orange.fr> <87hbjewshs.fsf@ludovic-brenta.org> <93564a8d-8ddb-42cb-a873-dc80f6773c25@m17g2000prl.googlegroups.com> In-Reply-To: <93564a8d-8ddb-42cb-a873-dc80f6773c25@m17g2000prl.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4c5707e9$0$14481$7b1e8fa0@news.nbl.fi> Organization: NBL Networks Oy NNTP-Posting-Host: 217.30.184.161 X-Trace: 1280772074 news.nbl.fi 14481 217.30.184.161:39134 X-Complaints-To: abuse@nblnetworks.fi X-Original-Bytes: 4046 Xref: g2news1.google.com comp.lang.ada:12811 Date: 2010-08-02T21:01:13+03:00 List-Id: Hi, Another Monotone user and (occasional) developer here. On 08/02/2010 07:21 PM, Marcelo Cora�a de Freitas wrote: > On 1 ago, 07:13, Ludovic Brenta wrote: >> This looks like the memory leak that was fixed in monotone version 0.27, >> back in 2006. And the latest version, 0.48, has additional performance >> improvements for very large trees. > > I am not quite sure we are talking about the same bug. This has been > detected in 2009/2010 and the Edward O'Callaghan from AuroraUX was in > touch with one of the monotone developers. I don't know exactly what > happened as I had to focus on other things. I am not sure is the poor clone/pull performance an actual bug. It could be related to the way Monotone is designed. First, different sections/layers of Monotone have abstracted interfaces. For example, you can swap network protocol or internal change set/database implementation with another and leave other parts untouched. This might affect performance, although in theory the impact should be small. Second, by default, Monotone uses backward deltas for change sets. This means that only the files in the latest revision are stored in their full form. Other revisions are recorded just as difference from their child revision. To build 10th newest revision (head-9) you need to apply deltas from head-1 to head-9 on top of head. And to build the first revision, you need to apply all deltas. The recent versions of Monotone also support forward deltas, but they need to be turned on explicitly, because then the disk space usage increases. Third, before sending or receiving anything, Monotone calculates sha1 checksums for the data. I am not totally sure, but I think that when you request full clone of a repository, Monotone constructs each revision (using those backward deltas) from first to latest and calculates checksums for them. This ensures data integrity but also takes somewhat long time. There have been experiments where the checksum calculation/checking has been removed and it has shown performance boost, but developers prefer to have those checks on. That checking has revealed data corruption and disk failures on real systems before operating system's own mechanisms have detected anything. Some references: 6 minute pull CPU time for AuroraUX with no checking: http://colabti.org/irclogger/irclogger_log/monotone?date=2010-02-12#l7 (No idea what was the actual wall clock time.) 20% increase in pull time for AuroraUX: http://colabti.org/irclogger/irclogger_log/monotone?date=2010-02-09#l147 (This improvement is in 0.47 or 0.48) -Tero