On Mon, Feb 06, 2006 at 07:38:10PM -0800, Joe Wilson wrote:
The monotone client in the initial pull was idle for minutes
at a time waiting for netsync (no I/O, no CPU). When the
netsync packets did arrive, the CPU hovered between 80% and
99% for a minute or two and then resumed being idle
On Tue, Feb 07, 2006 at 03:32:22AM -0800, Nathaniel Smith wrote:
In particular, netsync wants to send forward deltas, but if we store
forward deltas on disk, we have to traverse (potentially long) delta
chains when reconstructing files at 'checkout' time.
Actually, using backwards deltas, we
--- Matt Johnston [EMAIL PROTECTED] wrote:
Assuming the OS has sufficient memory available and sensible
buffering, shouldn't it be caching recently-written db
file portions already? We're currently committing a
transaction after every N bytes or M packets transferred,
which seems to be a
I noticed a recent post on the SQLite mailing list
(http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12839.html) asking
how monotone might
speed up its database access. Two simple optimizations that come to mind are:
(1) Use a larger default SQLite page size and/or cache size:
On Sun, Feb 05, 2006 at 02:39:34PM -0800, Joe Wilson wrote:
(1) Use a larger default SQLite page size and/or cache size:
As well as the other reasons, another advantage of this is that it
reduces the IO per-transfer overhead from everything between the
syscall layer and the disk, and probably
On Sun, 2006-02-05 at 14:39 -0800, Joe Wilson wrote:
[...]
(2) Use a :memory: database for the initial monotone pull and then dump the
resultant database
to file. This would eliminate the disk latency entirely. Since most monotone
databases I've seen
are generally under 100 megs, this is a
A ^C handler could be created to flush the contents to disk.
As for crashes, c'est la vie. ;-)
Even if this idea is not pursued, getting timings using a :memory:
db would give you a theoretical ideal database time. The remaining
time would be mostly attributed to monotone code itself and netsync
