From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun,  9 Jan 2011 17:02:24 -0500
To: 9fans@9fans.net
Message-ID: <21838e5aae362752a131f1c7ed5fa77b@ladd.quanstro.net>
In-Reply-To: <AANLkTikSFvfi-r0qm-bF7PGq0sSayyRBGAD9Z3ySpdsq@mail.gmail.com>
References: <16094d5a594bfa72dd0e9ac6f3f8b31c@plug.quanstro.net>
	<AANLkTin9Ft5OS2mgJ3y4Sh+DbpFvgPvCVh-hxJoT2Ed0@mail.gmail.com>
	<20110109195426.D1ED35B42@mail.bitblocks.com>
	<da8020577332c3641d8ba418cd1b9376@ladd.quanstro.net>
	<20110109213849.939D75B42@mail.bitblocks.com>
	<AANLkTikSFvfi-r0qm-bF7PGq0sSayyRBGAD9Z3ySpdsq@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] fs performance
Topicbox-Message-UUID: 93246194-ead6-11e9-9d60-3106f5b1d025

> John did do some measurement of file system times via the trace device
> we wrote. I think it's fair to say that the IO path for fossil is
> considerably slower than the IO path for kernel-based file systems in
> Linux: slower as in multiples of 10, not multiples. There's a fair
> amount of copying, allocation, and bouncing in and out of the kernel,
> and this activity does not come cheap.

that is, the pool library must die.

- erik