On Mon, 2005-10-31 at 10:53 -0800, Daniel Rall wrote:
> On Sat, 29 Oct 2005, Daniel Berlin wrote:
> > We use an external diff (GNU diff) client side, so the client profiles
> > don't show much time in subversion (Note: GNU Diff is significantly
> > faster than subversion's :P)
> I've heard quite a few requests to speed up the internal diff.
I even know how to do it (we are *too* optimal, GNU diff gives up much
quicker in favor of speed).
But we'd still use an external diff for -p support.
It's questionable whether we want to support every gnu diff option
> > It turns out our single-dir directory cache doesn't do so well.
> > In fact, we miss almost all the time.
> > Yet statistics show we end up asking for the dirents for same directory
> > 40 or 50 times in some cases, just not immediately again and again. The
> > obvious way to attack this is to increase the number of dirs cached in
> > the dirents to turn those into hits.
> Trading the possibility of increased memory footprint -- most of which
> Garrett is guessing comes from the pool allocated for each cache slot
> -- for a certain increase in speed is very reasonable for any usual
> use case (anything between multi-user network-accessible repository
> and a single-user local repository). Repository machines ought have
> enough memory to handle it.
I think so too.
I also wish their was some way to easily serialize the dirents (that
wasn't as slow as hash_read/hash_write), because then we could share
this over multiple svnserve invocations using memcache or something.
For gcc.gnu.org, this would be a win.
It has 8 gig of memory, so things rarely fall out of cache. We pay most
of the time in parsing/etc, not real i/o.
> Index: fs_fs.c
> --- fs_fs.c (revision 17091)
> +++ fs_fs.c (working copy)
> @@ -1739,11 +1739,17 @@ svn_fs_fs__rep_contents_dir (apr_hash_t
> fs_fs_data_t *ffd = fs->fsap_data;
> apr_hash_t *entries;
> apr_hash_index_t *hi;
> + unsigned int hid;
> + /* Calculate an index into the dir entries cache */
> + hid = svn_fs_fs__id_rev (noderev->id);
> + hid &= NUM_DIR_CACHE_ENTRIES - 1;
> Nice, that looks fast.
> This calculation is done in two different spots in this source file.
> How about a simple macro in fs.h?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 31 20:09:14 2005