On Mon, May 14, 2018 at 8:14 PM, Derrick Stolee <sto...@gmail.com> wrote: > I disagree with the removal of "generation". My intention is to make the > commit-graph feature a standard feature that most repos (of reasonable size) > want to have. In that case, 'graph_pos' and 'generation' will be set during > every parse and used by every commit walk. This is just my gut reaction.
My 'often used' is a poor choice of words. The problem here is memory consumption in full-repo walk like 'git clone' or 'git gc', where more memory use may equal more swapping and that will slow things down. commit-slab also has a few advantage over packing everything in struct commit besides the performance argument. It makes it easier to see what field is used for what. And if an operation only uses a field in a short time, then it's possible to free data after it's done (impossible to free these struct commits without a lot more thinking and checking; whatever you add here will stay until the end of the process, which could be a long time for things like pack-objects) > As I investigate these changes, I'll try to see what performance hit is > caused by converting the graph_pos and/or generation to commit slabs. > (Again, I'm assuming the slabs will make this slower. I may be wrong here.) The slab allocation code is very similar to memory-pool, which was made common code also by Microsoft to make reading cache faster so I don't think it will slow things down for you (again, guessing, no real measurement from my side). This does make me think it may be a good idea to try unify commit-slab and memory-pool, let commit-slab be a thin layer on top of memory-pool or something like that (the fewer custom mem allocators we have, the better) -- Duy
