On Wednesday 26 August 2009, Andreas Ericsson wrote: > Alex Riesen wrote: > > On Wed, Aug 26, 2009 at 14:56, Johan Herland<johan@xxxxxxxxxxx> wrote: > >> On Wednesday 26 August 2009, Alex Riesen wrote: > >>> On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@xxxxxxxxxxx> wrote: > >>>> The 256-tree structure is considerably faster than storing all > >>>> entries in a > >>> > >>> This part is confusing. Was 256-tree better (as in "faster") > >>> then? > >> > >> 256-tree is faster than the everything-in-hash_map draft. > >> 16-tree is slightly faster than 256-tree > >> > >> 256-tree uses more memory (in the worst case) that the > >> everything-in-hash-map draft. > >> 16-tree uses less memory than both. > >> > >> Makes sense? > > > > Oh, it does, it is just confusingly presented. How about: > > > > The 16-tree is both faster and has lower footprint then 256-tree > > code, which in its turn is noticably faster and smaller then > > existing hash_map implementation. ... > > If it's to be squashed in, why mention the 256-tree at all (except > for possibly as something to compare with at the end)? > If it goes on top, why mention the hash_map at all? Ah. Sorry for the confusion. These patches are not meant to standalone patches in the jh/notes series. They just compare various solutions to the problem of parsing a notes tree structure with fanout in an efficient manner. The next iteration of the jh/notes series will include the preferred solution (16-tree unless something better shows up), _without_ talking about the differences between alternative solutions. As such the hash_map and 256-tree will not be mentioned at all. ...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