Remove protobufjs in favor of protons-runtime

[v1rtl]

This closes #31

Switches to protons-runtime

All tests pass now

[alanshaw]

@talentlessguy you might gain more savings switching to protons and protons-runtime instead? It would dudupe with protons-runtime in ipfs-unixfs-exporter.

[alanshaw]

Note: I think in general I'd prefer to switch to protobuf-es as it seems to have a big community and usage behind it.

[v1rtl]

@talentlessguy you might gain more savings switching to protons and protons-runtime instead? It would dudupe with protons-runtime in ipfs-unixfs-exporter.

thanks for the suggestion

[achingbrain]

FWIW, last time I ran the benchmark suite, protons was just over 20% faster than protobuf-es when serializing/deserializing - https://github.com/ipfs/protons/tree/main/packages/protons-benchmark#usage

These kind of performance characteristics are very important to high traffic deployments like Lodestar so it's unlikely to be switched away from elsewhere.

[v1rtl]

FWIW, last time I ran the benchmark suite, protons was just over 20% faster than protobuf-es when serializing/deserializing - https://github.com/ipfs/protons/tree/main/packages/protons-benchmark#usage

do you mean protobufjs, and not protons?

[achingbrain]

No, I mean protons:

protobuf.js is also quite a bit faster than protobuf-es but it's CJS and the stack is ESM-only so that rules it out.

[v1rtl]

I wonder how hard it would be to replace protobuf-es with protons, will give it a shot rn

[achingbrain]

I guess the only thing is that protons compiles protobuf definitions to TypeScript and this is still a js project.

[alanshaw]

@achingbrain is the benchmark encode or decode? We're only encode in this repo.

[v1rtl]

Had to remove certain dead code that apparently was detected before to make CI pass (otherwise the coverage is too low). Should I open a separate PR to eliminate all dead code? To make it easier to review the current PR