refactor: use faster-eth-utils for better performance

[BobTheBuidler]

What I did

This PR implements faster-eth-utils, my faster fork of eth-utils.

Benchmarks are available here.

Checklist

• Passes all linting checks (pre-commit and CI jobs)
• New test cases have been added and are passing
• Documentation has been updated
• PR title follows Conventional Commit standard (will be automatically included in the changelog)

[fubuloubu]

wouldn't it make sense to re-export this via your package? (to maintain compatibility)

[BobTheBuidler]

Yeah that's a good idea but it isn't currently implemented and I have a bit of a pile in front of me to work thru first. Up to you how to handle it here for the time being. The faster implementation is still faster, just less magnitude of difference.

[BobTheBuidler]

The most recent faster-eth-utils now uses the implementation from cchecksum

So it depends on how tight you'd like the pin to be

[fubuloubu]

Overall, what platforms/architectures does this new package support?

[BobTheBuidler]

It supports all CPython distros >= 3.8

[BobTheBuidler]

Just # type: ignore'd the type error.

[fubuloubu]

Just # type: ignore'd the type error.

oof, needs noqa: E501 at the end of it

[BobTheBuidler]

done

[BobTheBuidler]

bro what? evidently we can't have a type: ignore and a noqa: on the same line

should we just break up that line?

[fubuloubu]

bro what? evidently we can't have a type: ignore and a noqa: on the same line

should we just break up that line?

sure, sounds fine

do you have any benchmarks for practical use in this repo btw? would be helpful!

(as a maintainer's note, this is a pretty safe repo to introduce this dependency to as it's very performance-sensitive, but has few down-stream dependencies that are other libraries)

[BobTheBuidler]

wym "practical use"? I have benchmarks for all modules with a variety of input args. Is that what you're looking for?

[BobTheBuidler]

but has few down-stream dependencies that are other libraries

What types of issues were you thinking of here?

[fubuloubu]

wym "practical use"? I have benchmarks for all modules with a variety of input args. Is that what you're looking for?

I mean with silverback in action using the updated package

[fubuloubu]

but has few down-stream dependencies that are other libraries

What types of issues were you thinking of here?

I'm hesistent to do it with ape / ape plugins / our more core infra packages yet until I understand any package conflicts or impacts, however Silverback is really mostly an end-user package (not meant to be used as a library, only as a framework for bot running) so the impact is rather limited. If it works well, then we can work on introducing it up the stack

[BobTheBuidler]

wrt deps: the dependencies match the eth-utils dependencies for the version each release is based on if you use 4.x.x you should be able to drop in 4.x.x without any conflicts, and same for 5.x.x

[BobTheBuidler]

wym "practical use"? I have benchmarks for all modules with a variety of input args. Is that what you're looking for?

I mean with silverback in action using the updated package

Oh no I don't have anything like that. But drop it in one to your most cpu-hungry bots and lmk!

[BobTheBuidler]

I just ran black . locally and it tried to reformat not only this file but also main.py

So I pushed the changes it made to utils.py ONLY but can't say for sure that the changes were correct for your repo config, we'll see

[BobTheBuidler]

finally, all green!