[RFC/PATCH INTRO] rev-cache

2 messages, 1 author, 2016-06-15 · open the first message on its own page

[RFC/PATCH INTRO] rev-cache

From: Nick Edelen <hidden>
Date: 2016-06-15 22:47:01

Hi everyone, 

I've been working on a revision caching system (with gsoc), and would be curious to get some feedback on it and it's (potential) installation into git.  I believe the core mechanics of it are largely finished, but integration is still rather rough.  I've tried to divide it into 4 self-contained patches -- each representing a working implemenation with incremental featuresets.  The patchset is seperated as:
 * basic - the simplest working revision cache implementation, with full docs and relavant tests
 * objects - non-commit object caching + tests
 * misc - extra (maintenance) features and refactor of object caching (requiring slight modification of some object structures)
 * integration - (proof of concept) integration of rev-cache into rev-list, along with extensive tests

I'm afraid the first patch is rather big, as the topo-data encoding scheme is a smidgen complicated, but its effect on git's internals is very small -- it's less of a patch and more an addition of a few files.  I know you guys prefer inline patches, but in view of the patchfile size I decided it'd be more prudent to include that seperately as an attachment.  The only other caveat I can think of is that the tests currently require python, although that could change in future.

So yeah, I hope you find it interesting.  Apologies if I'm breaking protocol...

 - Nick

Re: [RFC/PATCH INTRO] rev-cache

From: Nick Edelen <hidden>
Date: 2016-06-15 22:47:04

hi all,

understandably, someone dumping a load of source without much comment
on you guys didn't exactly enthrall you.  this project feels pretty
finished, so I'm not in desperate need of feedback, but I figured you
guys might like some high-level info on my part.  I've modified the
integration bit slightly, and performance is now reasonably
satisfactory.  here are some stats for the linux repo (~270MB) on my
laptop:

( note that I've edited the last patch (integration) a bit, so I've
attached the new patch.  I've also, in a seperate patch, tweaked
builtin-pack-objects to reduce a bottleneck in object checking/writing
(also attached). )

git-rev-list --all --objects >/dev/null
default     : ~55s
w/ rev-cache: ~8s

git-pack-objects --revs --all --stdout >/dev/null
default             : 4m 48s (cold); 3m 41s (warm)
w/ rev-cache        : ~58s
w/ rev-cache + tweak: ~36s

I tested these on cygwin on a dual-core laptop with 1gb ram, with a
few apps running in the background.  times could vary a bit, depending
on what's been run how many times with what in the background, etc.,
but I tried to capture the general trend.

 - Nick

On Fri, Jul 3, 2009 at 5:13 PM, Nick Edelen[off-list ref] wrote:
Hi everyone,

I've been working on a revision caching system (with gsoc), and would be curious to get some feedback on it and it's (potential) installation into git.  I believe the core mechanics of it are largely finished, but integration is still rather rough.  I've tried to divide it into 4 self-contained patches -- each representing a working implemenation with incremental featuresets.  The patchset is seperated as:
 * basic - the simplest working revision cache implementation, with full docs and relavant tests
 * objects - non-commit object caching + tests
 * misc - extra (maintenance) features and refactor of object caching (requiring slight modification of some object structures)
 * integration - (proof of concept) integration of rev-cache into rev-list, along with extensive tests

I'm afraid the first patch is rather big, as the topo-data encoding scheme is a smidgen complicated, but its effect on git's internals is very small -- it's less of a patch and more an addition of a few files.  I know you guys prefer inline patches, but in view of the patchfile size I decided it'd be more prudent to include that seperately as an attachment.  The only other caveat I can think of is that the tests currently require python, although that could change in future.

So yeah, I hope you find it interesting.  Apologies if I'm breaking protocol...

 - Nick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help