11–20 of 94 posts
> It’s mysterious that Rust’s release version with -i ran slightly faster, though. That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements. The Nim version uses instead hash tables, whose lookup time is near-c…
I'd guess that pulling that try-catch out of the loop would make things go much faster. Nim doesn't use 0-overhead exceptions, so setjmp needs to be called each time the try-catch is entered. You should also use the re module, PEGs is not nearly as optimized as PCRE.
I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
> It’s mysterious that Rust’s release version with -i ran slightly faster, though. That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements. The Nim version uses instead hash tables, whose lookup time is near-c…
That should explain it. I’ve removed the line as it’s no more mysterious...
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)
> It’s mysterious that Rust’s release version with -i ran slightly faster, though. That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements. The Nim version uses instead hash tables, whose lookup time is near-c…
Not criticizing, just curious.
Earlier quoted context omitted.
That should explain it. I’ve removed the line as it’s no more mysterious...
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…
I'm starting to really wish there was a GC-free (or at least) GC optional version of Nim. Nim with Rust's memory semantics would just be the best of everything.
I believe you can turn off the GC for Nim. Then you're just limited to libraries that don't rely on the GC, and fully manual memory management.
For example:
proc printf(formatstr: cstring) {.header: "", importc: "printf", varargs.}
> It’s mysterious that Rust’s release version with -i ran slightly faster, though. That's actually not surprising: a large fraction of time is spent in the map lookup, which in Rust is implemented as a B-tree, thus lookup time is (mildly) dependent on the map size. If keys are lowercased before inserting them, the map ends up having fewer elements. The Nim version uses instead hash tables, whose lookup time is near-c…
This seems an odd choice to me (default to B-Tree instead of hash map). I'd expect a sorted map to be a special case, not a general one. Do you happen to know the rationale? Not criticizing, just curious.
http://doc.rust-lang.org/std/collections/
Use a HashMap when:
- You want to associate arbitrary keys with an arbitrary value.
- You want a cache.
- You want a map, with no extra functionality.
Use a BTreeMap when:
- You're interested in what the smallest or largest key-value pair is.
- You want to find the largest or smallest key that is smaller or larger
than something
- You want to be able to get all of the entries in order on-demand.
- You want a sorted map.