monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: [PATCH] pre-cache database file to improve resp


From: Benoît Dejean
Subject: Re: [Monotone-devel] Re: [PATCH] pre-cache database file to improve response time
Date: Mon, 20 Mar 2006 20:36:58 +0100

Le dimanche 19 mars 2006 à 19:06 -0800, Joe Wilson a écrit :
> Benoît Dejean wrote:

> ...yet in spite of this, people still use DVD burning software to 
> burn multi-gigabyte disk images while running background tasks.
> The OS can swap pages back out just as easily.

i think this is irrelevant. sqlite does random writes/reads. moreover,
if you cat'ed your dvd iso before burning it, that wouldn't speed at all
the burning process. but you get the point, if you're running out of
ram, the kernel destroys cache pages that have just been read by your
'preload' :)

> If required, an upper pre-cache memory limit can be set easily enough.
> The longer running monotone commands hit most pages in the database 
> anyway. The speed up of many commands is quite dramatic.

on small databases, i get exactly the same performance boost -- on
startup -- for small operations -- if i do twice the same commands.

> Try the patch before forming an absolute opinion. It works quite 
> well in practice and does not affect the other processes in my testing
> (iTunes does not appear to be bothered).

my database is 180MB, trust me when i say that cat'ing it is useless.
linux cache+buffer on my desktop is about 100MB. reading the whole file
is slow, and monotone is unlikely to access every single byte of the
database. so it just trashes the cache.

i've tested on net.venge.monotone with cold cache :
- monotone log --last 1 : 4.3s
- cat + monotone status : 3s + 2s

but of course, with hot cache : 1.5s

swapping back to evolution to finish this email : about 4s ...

> 
> Until SQLite uses mmap() instead of read(), I don't see another way to 
> speed up monotone disk read access nearly as easily and effectively.
> 

Again, i don't think this is a scalable solution. this may only give a
short boost on startup with small databases. otherwise, it may just slow
the whole startup. I'm happy that not every single app on my computer do
this. ram is a precious resource.
my main concern is CPU consumption. this is the very limiting factor of
monotone on my computers.

cheers.

-- 
GNOME http://www.gnomefr.org/
LibGTop http://directory.fsf.org/libgtop.html

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


reply via email to

[Prev in Thread] Current Thread [Next in Thread]