Re: [PATCHv5 00/14] git notes
From: Johan Herland <hidden>
Date: 2016-06-15 22:47:23
On Tuesday 08 September 2009, Johan Herland wrote:
Algorithm / Notes tree git log -n10 (x100) git log --all ------------------------------------------------------------ before / no-notes 4.78s 63.90s before / no-fanout 56.85s 65.69s 16tree / no-notes 4.77s 64.18s 16tree / no-fanout 30.35s 65.39s 16tree / 2_38 5.57s 65.42s 16tree / 2_2_36 5.19s 65.76s flexible / no-notes 4.78s 63.91s flexible / no-fanout 30.34s 65.57s flexible / 2_38 5.57s 65.46s flexible / 2_2_36 5.18s 65.72s flexible / ym 5.13s 65.66s flexible / ym_2_38 5.08s 65.63s flexible / ymd 5.30s 65.45s flexible / ymd_2_38 5.29s 65.90s flexible / y_m 5.11s 65.72s flexible / y_m_2_38 5.08s 65.67s flexible / y_m_d 5.06s 65.50s flexible / y_m_d_2_38 5.07s 65.79s
Ok, I have been pondering this back and forth, and I'm not sure what to think. It seems allowing (not mandating) date-based fanout gives a slight runtime advantage if used correctly, but I'm not sure the slight runtime improvement is worth the added code complexity and worse maintainability. I'm starting to lean against SHA1-based fanout being "good enough". But when we look at the memory consumption, it's clear that SHA1-based fanout loses out (because you cannot throw away subtrees without fear that they will be needed again soon). Then again, memory consumption has not been the major focus of the git project, and 14 MB (for holding all ~157000 notes in the kernel repo example) is not excessive for an average desktop computer. Shawn, do you have any additional defence for the date-based fanout? Are there untested reasonable scenarios that would show the benefits of date- based fanout? How does the plan for notes usage in your code-review thingy compare to my test scenario? ...Johan -- Johan Herland, [off-list ref] www.herland.net