Sam Vilain <sam@xxxxxxxxxx> writes: > This patch series describes the structure of the object list cache > on-disk format. It is built successively from a very simple design - > just an object list - to a version that allows for as many rev-list > operations to be accelerated as possible, and potentially immediate > startup of full clone operations in the common case; ie skipping the > "Counting Objects" and "Compressing Objects" phase once a matching > index is found. > > The plan will be to implement each step incrementally, with a test-*.c > file along the way which tests the API provided by the revision cache > API. While the revision cache format will change along the way, this > will not require an index format deprecation cycle, as integration with > the rest of git will not happen until the format is settled. > > The plan is to aim for one of these API milestones completed per week. > When complete, each commit will contain tests for the level of cache > that it delivers. Later milestones include joining the dots - > integrating with the 'rev-list' machinery and most importantly, > 'pack-objects'. I like this sharing not only completed code, but plans, designs (and status reports) with Git Development Community (i.e. git mailing list). I like this very much. I'd like to ask if there any results of profiling git server (git-daemon) code: how much is spend on object enumeration this GSoC project tries to make faster by the means of caching? Are there prepared benchmarks and tests to check if the code gives correct results, and to measure improvements brought by caching? Would it be possible to get some real-life statistics of git-daemon usage, so that you optimize against real scenarios? I wish you good work on git-daemon caching... -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html