{"thread":{"id":"29659","subject":"Does pack v4 do anything to commits?","startedAt":"2012-02-18T04:44:40Z","lastAt":"2012-02-18T15:34:43Z","messageCount":2,"participants":["Nguyen Thai Ngoc Duy","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184918","messageId":"CACsJy8CZPG3b3LBF-EFO_kOv6i157jy5414+bHcqiwOKyC+8VA@mail.gmail.com","threadId":"29659","inReplyTo":null,"subject":"Does pack v4 do anything to commits?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-18T04:44:40Z","receivedAt":"2012-02-18T04:44:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi Nico,\n\nI had an experiment on speeding up \"rev-list --all\". If I cache sha-1\nof tree and parent, and committer date of single-parent commits, in\nbinary form, rev-list can be sped up significantly. On linux-2.6.git,\nit goes from 14s to 4s (2s to 0.8 for git.git). Profiling shows that\ncommit parsing (get_sha1_hex, parse_commit_date) dominates rev-list\ntime.\n\n>From what I remember, pack v4 is mainly about changing tree\nrepresentation so that we can traverse object DAG as fast as possible.\nDo you do anything to commit representation too? Maybe it's worth\nstoring the above info along with the compressed commit objects in\npack to shave some more seconds.\n\nBy the way, is latest packv4 code available somewhere to fetch?\n-- \nDuy\n"},{"id":"184932","messageId":"alpine.LFD.2.02.1202181013350.24536@xanadu.home","threadId":"29659","inReplyTo":"CACsJy8CZPG3b3LBF-EFO_kOv6i157jy5414+bHcqiwOKyC+8VA@mail.gmail.com","subject":"Re: Does pack v4 do anything to commits?","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2012-02-18T15:34:43Z","receivedAt":"2012-02-18T15:34:43Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 18 Feb 2012, Nguyen Thai Ngoc Duy wrote:\n\n> Hi Nico,\n> \n> I had an experiment on speeding up \"rev-list --all\". If I cache sha-1\n> of tree and parent, and committer date of single-parent commits, in\n> binary form, rev-list can be sped up significantly. On linux-2.6.git,\n> it goes from 14s to 4s (2s to 0.8 for git.git). Profiling shows that\n> commit parsing (get_sha1_hex, parse_commit_date) dominates rev-list\n> time.\n> \n> >From what I remember, pack v4 is mainly about changing tree\n> representation so that we can traverse object DAG as fast as possible.\n> Do you do anything to commit representation too? Maybe it's worth\n> storing the above info along with the compressed commit objects in\n> pack to shave some more seconds.\n\nBoth the tree and commit object representations are completely changed \nto evacuate SHA1 parsing and searching entirely.  The SHA1 references \nare uncompressed, and replaced by indices into the pack for direct \nlookup without any binary search.  And the commit dates are stored in \nbinary form. All path names as well as author/committer names are \nfactored out into a table as well. This should make history traversal \noperations almost as fast as walking a linked list in memory, while \nmaking the actual pack size smaller at the same time.\n\n> By the way, is latest packv4 code available somewhere to fetch?\n\nWell, not yet.  Incidentally, I'm going in the Caribbeans for a week in \na week, with no kids and only my wife who is going to be busy with scuba \ndiving activities.  Like I did last year, I'm going to take some time to \npursue my work on Pack v4 during that time.  And I intend to publish it \nwhen I come back, whatever state it is in, so someone else can complete \nthe work eventually (I have too much to do to spend significant time on \nGit these days).\n\n\nNicolas\n"}]}