`hex_bytes` is slow about rust-bitcoin

[TheBlueMatt]

Some options: https://godbolt.org/z/C34XMV (looks like the biggest code-size/branch-count diff is the as_bytes() change, though the branch predictor may optimize most of that away given the input is all ASCII, the Pairable iterator, if you make it non-pub, doesn't seem to add much to the code size).

That said, I don't see why we need to keep around a pub Pairable iterator in rust-bitcoin, seems way out of scope. I wouldn't really be surprised if the biggest CPU user was realloc and the with_capacity change were the biggest winner, but may be worth benchmarking some of those options.

[sgeisler]

I did some benchmarking using @TheBlueMatt's implementations, the current one and two I wrote myself. You can find the code here and the results on my T480s/i7-8650U CPU @ 1.90GHz here.

On my machine my completely non-functional-style implementation is currently the fastest one (465ns with the current code -> 76ns with mine for 32bytes, @TheBlueMatt's second solution takes 95ns). I even think it's quite readable, but I might be a bit biased 😄

The reason why we can't use the Chars iterator is quite sad: to me it seems that handling unicode codepoints isn't much more complicated than ascii characters, but what makes it inefficient in the end id that the size_hint is way off (lower bound is len()/4 because of the max. UTF8 character size). That means we get many more allocations than necessary. At first I had an implementation using characters but this turned out to be a complete show stopper. I could have built a wrapper iterator struct that lets me add size hints after the fact, but imo it would still be slower then the currently fastest solutions or completely unreadable if written in a functional style.

You can benchmark it using cargo bench. If it's well received I'll PR my solution.

[dpc]

Now we know what are the ballparks here for original, and possibly optimal solution. I agree that lack of unsafe is more important and I'm personally satisfied with current speedup. Thank you for working on it! I'll patiently await when this lands and gets released.

[dpc]

@sgeisler I don't think it's going to add anything, but just for double-checking: can you bench with a 4MB worth of hex-encoded data? That corresponds to a biggest hex string that could potentially be hex-decoded in Bitcoin, if I'm not mistaken.

[sgeisler]

I did the benchmark with 4M again and the result shows a much smaller difference between the current and the better implementations (which can be expected due to memory latency/cache misses).

In terms of throughput the best implementation achieves 260MByte/s input or 130MByte/s output. That somehow doesn't sound really good to me, but also not horrible. One could try out a lookup table approach, but I won't right now.

[dpc]

https://github.com/nervosnetwork/faster-hex/ could be used as a datapoint too

[sgeisler]

That's a really nice crate 😃 but avoiding unsafe is probably the bigger concern than speed in this case imo (except someone wants to do a really thorough review on it, but I doubt it), it also seems to require the 2018 edition of rust, which we won't be able to use for some time (#206).

The stats for 256bytes:

• current: 1773 ns
• optimized: 464 ns
• faster-hex: 98 ns

The effect is even noticeable for 64 bytes but not that strongly.

Fun fact: switching to the current stable (because of faster-hex) made the current code 45% faster 😆

[TheBlueMatt]

Nice work, PRs welcome :p

…

On Jan 3, 2019, at 19:37, Dawid Ciężarkiewicz ***@***.***> wrote: Now we know what are the ballparks here for original, and possibly optimal solution. I agree that lack of unsafe is more important and I'm personally satisfied with current speed. Thank you for working on it! I'll patiently await when this lands and gets released. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.