3 ms·

That should explain it. I’ve removed the line as it’s no more mysterious...

• ot 12y ago
  You're still comparing two different data structures. Is there a good hash table in Rust? If you use that instead of the B-tree, I would expect it to be at least as fast as Nim. B-trees are especially bad for string keys, because comparisons are expensive. EDIT: From Rust docs: "Currently, our implementation simply performs naive linear search. This provides excellent performance on small nodes of elements which are cheap to compare". (emphasis mine)
  • arthurtw 12y ago
    It turns out `collections::HashMap` runs about 6~7% faster than BTreeMap. I will update the article to include results of both data structures.
    • tikue_ 12y ago
      Also seems like you could benefit from the entry() api (available on both BTreeMap and HashMap): http://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.entry http://doc.rust-lang.org/std/collections/struct.BTreeMap.htm... I think the example used in the docs is your exact use case. This bit: let found = match map.get_mut(..) { .. } if !found { .. } can be replaced with match map.entry(word) { Occupied(mut view) => { *view.get_mut() += 1; } Vacant(view) => { view.insert(1); } }
      • arthurtw 12y ago
        Good point! I’ve updated the article accordingly. I learned the Entry thing a few months ago, but Rust’s BTreeMap did not support the entry API at that time, so my code did not use it. Then I totally forgot about it when writing this blog...