Re: [RFC] Possible idea for GSoC 2020
- From
Abhishek Kumar <abhishekkumar8222@gmail.com>
- Date
- Mar 17, 2020, 17:00 UTC
- Message-ID
- <CAHk66ftx=XTSeVcPe09yA9KMDpHwiKFLKa62cCBFufjeenAbaQ@mail.gmail.com>
Show 11 quoted lines
> Having such a complicated two-dimensional system would need to > justify itself by being measurably faster than that one-dimensional > system in these example commands. > > [...] > > My _prediction_ is that the two-dimensional system will be more > complicated to write and use, and will not have any measurable > difference. I'd be happy to be wrong, but I also would not send > anyone down this direction only to find out I'm right and that > effort was wasted.
Agreed. I have been through the papers of the involved variants and on graphs comparable to some of the largest git repositories, the performance improves by fifty nanoseconds for a random query.
Additionally: 1. They require significantly more space per commit. 2. They require significantly more preprocessing time.
Show 5 quoted lines
> My recommendation is that a GSoC student update the > generation number to "v2" based on the definition you made in [1]. > That proposal is also more likely to be effective in Git because > it makes use of extra heuristic information (commit date) to > assist the types of algorithms we care about.
Show 6 quoted lines
> In that case, the "difficult" part is moving the "generation" > member of struct commit into a slab before making it a 64-bit > value. (This is likely necessary for your plan, anyway.) Updating > the generation number to v2 is relatively straight-forward after > that, as someone can follow all places that reference or compute > generation numbers and apply a diff
Thanks for the recommendation. Reading about how this fits in more with REU on the other thread, I too agree that updating generation number to use corrected commit date would be more appropriate for a GSoC project.
Regards Abhishek