From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Anthony Sorace In-Reply-To: <87C61423-7C13-4516-88B5-C2ABA7D32AA9@me.com> Date: Mon, 4 May 2015 12:10:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87C61423-7C13-4516-88B5-C2ABA7D32AA9@me.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] fossil+venti performance question Topicbox-Message-UUID: 4ee0ef5e-ead9-11e9-9d60-3106f5b1d025 The reason, in general: In a fossil+venti setup, fossil runs (basically) as a cache for venti. If your access just hits fossil, it=E2=80=99ll be quick; if not, you hit the (significantly slower) venti. I bet if you re-run the same test twice in a row, you=E2=80=99re going to see dramatically improved performance. Try it. If that=E2=80=99s true, the question is really one of venti performance; if not, you may have another system config issue. There are various changes you can make to how venti uses disk/memory that can speed things up, but I don=E2=80=99t have a good handle on which to suggest first. Your write performance in that test isn=E2=80=99t really relevant: they=E2=80=99re not hitting the file system at all. I=E2=80=99m not sure why you=E2=80=99d see a difference in a fossil+venti setup of a different size, but the partition size relationships, and the in-memory cache size relationships, are what=E2=80=99s mostly important. a