Thanks for your comments! On 02/03/2013 10:54 AM, Tim Chevalier wrote: > On Sat, Feb 2, 2013 at 12:49 PM, Tommy M. McGuire <[email protected]> wrote: >> https://github.com/tmmcguire/rust-toys/blob/master/mk_anadict.rs >> >> For inspiration (and because I have no actual creativity of my own), I >> picked up >> http://www.jeffknupp.com/blog/2013/01/04/creating-and-optimizing-a-letterpress-cheating-program-in-python/, >> which is basically an anagram solution generator; this first program >> generates a text dictionary of letter sequences to words, one mapping >> per line. >> >> I'm using Rust 0.5. >> ... >> * For no readily apparent reason, I used @[] quite a bit. Should there >> be any special preferences for ~[]? >> > > No, at least not until you're writing code with multiple tasks or > where you care about performance. It's fine to start with @[] and then > change to ~[] as needed. As with @str, there's less library support > for @[], but that's another thing we need to work on.
Actually, performance was going to be my next question. mk_anadict started out as a direct translation of the Python code and it produces (nearly) the same output. Unfortunately, it currently takes approximately 3x as long. The one major change I made was in producing the output; the Python version does a single write, joining all of the lines produced individually in an array. That, in Rust, was even slower than the current code. There seems to be a lot of memcpy's going on, but I don't see why and I'm not sure that would explain the difference. Is there anything obvious? (I've just started playing with perf, as well.) > There are a few places where you call a function like > str::len(**line), where line.len() would be more idiomatic (and > because of auto-dereference, you're saved from writing the asterisks). > I'll let others point out other nits :-) > > Cheers, > Tim > -- Tommy M. McGuire [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
