It turns out not to be that fancy in gzip's harness.

It seems to be tiny bit faster than slice-by-8 during decompression but slower during compression; to the point of being on par with current Sarwate algorithm, or tiny bit faster ( paste.ee/p/QeBKL ).

Benefits are not that unambiguous. Though I didn't make that slicing-by-8 ( paste.ee/d/mkqTU/0 ) work with gzip properly, I would consider it in a context of application itself. If braids are faster with decompression, not much though, and slower with compression, then it would make sense to weight it somehow in this context and asses fitness for this particular application.

Either way, whichever algorithm would be chosen it still would make sense to generate crc table dynamically, when program starts. It takes, on my turtle computer, less than 10 us. Even rolled version. Unrolled isn't much faster either (10%-20%).

Using already generated 'Sarwate's' table  as a basis, halves that time.

That's imperceptible differences. None is going to notice that, even with atomic clock.