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, <johan@xxxxxxxxxxx> www.herland.net -- 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