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?
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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