Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes

On Wednesday 26 August 2009, Andreas Ericsson wrote:

Alex Riesen wrote:

quoted

On Wed, Aug 26, 2009 at 14:56, Johan Herland[off-list ref] 

wrote:

quoted

quoted

On Wednesday 26 August 2009, Alex Riesen wrote:

quoted

On Wed, Aug 26, 2009 at 12:31, Johan Herland[off-list ref] 

wrote:

quoted

quoted

quoted

quoted

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, [off-list ref]
www.herland.net