invite/challenge for fun & profit

In my a efforts to learn Rust I decided to create a strutil package containing common string functions and compare them to Go; this is not a Go vs Rust comparison, I merely decided to take a language I know well and compare it to it's Rust counterpart code. https://github.com/rust-playground/strutil There are only a couple of functions currently but am looking to add more as I go.

I am attempting to create the most efficient and idiomatic Go & Rust code possible and would like to invite/challenge the community to contribute in making the best code possible!

Hopefully everyone can learn something new

If you can make any of the functions more efficient, with better throughput or less allocations, ... make a pull request, I'll test and if it beats the current implementation I'll merge and now you're the one to beat!

---

评论：

djherbis:

The strings you're benchmarking on seem too small imho to actually see real perf. differences.

I think your "large" examples should contain much more data to get a better benchmark, otherwise noise will likely triumph.

dean_karn:

Thanks @djherbis how long would you suggest? Or if you have an example I'd definitely add it :)

djherbis:

For happy paths (returns true):

For palindromes, generate some long string of random runes and then just reverse them and add forward + backward string to get a generated palindrome (it's pretty easy to change this to have 'unique middle' char if you want).

For anagrams, generate a long string of random runes, and then use rand.Perm to get a random permutation of them (which will be an anagram).

(you should probably save the generated strings for re-use so your tests are repeatable)

This lets you generate arbitrarily big test data, I'd probably start with ~1000 runes and compare a few implementations to see what kind of perf. difference I see after running it a number of times. I'd fiddle with the size of the generated test cases (* or / by powers of 2) until I saw a significant difference in perf.

Some implementations might optimize for different cases too (like expecting unhappy vs. happy path vs. balanced).

I think these kinds of challenges are neat, have fun!

dean_karn:

Thanks, I will implement immediately..done

tv64738:

I am attempting to create the most efficient and idiomatic Go & Rust code possible

5 seconds in:

https://github.com/go-experimental/strutil/blob/18f1abbe29f10d870520c262784321c8233e840e/strutil.go#L11

ar1819:

This will not work when two or more runes produces one symbol.

Unicode is hard... 

karnd01:

You are correct @ar1819 these functions only support single unicode runes symbols not multiple rune symbols, I'll add that to the documentation of these functions, thanks :)

As a side note could you provide an example of a multi-columns symbol? I'd love to take a look and see what's possible.

ar1819:

Here you go:
https://play.golang.org/p/CVXNYEVFmA

Robonia:

So would normalizing the runes fix this issue?

ar1819:

No - the results would become invalid:
https://play.golang.org/p/klXld3DSBu

dean_karn:

I'm afraid I don't understand your comment? but if your suggesting there's a better way, please let me know :)

tv64738:

In which case you probably shouldn't be aiming to create "the most efficient" anything, at this time. Sorry.

dean_karn:

@tv64738 if you have nothing positive to contribute, why are you even commenting here?

I hear a lot of negativity and no suggestions for improvement, which is what this whole endeavour is about...so I will assume you have none :)

tv64738:

Because you're misleading people into thinking something there is efficient, idiomatic, and a good comparison of two things.

An improvement would be reading about how the things you're trying to create work. For example, understanding why that one line is unlikely to show up in any "most efficient" anything.

PaulCapestany:

It's too early in the morning, so I might be missing something obvious, but what's inefficient about casting a string to a slice of runes?

ar1819:

Because of the additional allocation, with copying perhaps? There is no way to get reverse iterator in Go, and indexing string returns byte and not rune. Still, this is not a reliable way to tell if the string is a palindrome. See comment below about that.