mrhooray / crc-rs

Rust implementation of CRC(16, 32, 64) with support of various standards

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Differences between function and trait based operation

chrysn opened this issue · comments

Utilizing the crc crate with the crc64::Digest::new(crc64::ECMA) and core::Hasher interface, I was taken aback by the cost of it creating and allocating a table on the stack every time I start a new digest, which is prohibitive in an embedded environment.

The short-hand format checksum_ecma(...) is convenient only as long as data is available in a single run; I had to fall back to defining the field u64 and passing it through update, which is by far not as elegant as using the core::Hasher trait.

As I don't quite understand the reason for the different interfaces, I can make only uninformed suggestions on how the crate's behavior would be better suitable for my needs:

  • There could be a slimmer type wrapper around the intermediates that makes the static tables of update() available with a core::Hasher interface.
  • The Digest struct could become more general to allow building a Digest that uses the static tables.
  • The various two interfaces could be told apart in the README; right now the examples read as if checksum_x25 were just a shorthand for the later crc16::Digest::new(crc16::X25) with write and sum16, while actually it's doing vastly different things performance-wise.

Please provide feedback on #48. It might address your use cases.

If v2 is accepted, this can be closed as "fixed by that".