search

alecthomas / go_serialization_benchmarks

Benchmarks of Go serialization methods
https://alecthomas.github.io/go_serialization_benchmarks/
1.56k stars 158 forks source link

goserbench: Make this package a module #144

Closed matheusd closed 3 months ago

matheusd commented 3 months ago

This makes the goserbench package into its own module. This allows third parties to import the main benchmark procedure without having to require any of the tested serializers.

The goal of this split is to allow serializer projects to themselves import the benchmark code to ease development and verification of the benchmark numbers, without having to depend upon any of the other serializers tested in this repository.

The main go.mod file is modified to ensure running the benchmarks locally always uses the local version of the goserbench package. This commit also tidies the go.mod and go.sum file.

After this is merged to the master branch, a new tag can be created (such as goserbench/v0.1.0) to ensure users can require a stable version of the new goserbench module.

alecthomas commented 3 months ago

I'm not going to merge this. Maintaining multi-module source trees is very tedious, and the advantage is minor. I think now that the benchmarks are modular, writing a new benchmark is quite straightforward from within the repo.

matheusd commented 3 months ago

The goal was not to make it easier to write new benchmarks in this repo, but rather to allow serializer writers to benchmark the code in their codebases, to check their own evolution, without having to import every serializer.

So, for example, I can go to https://github.com/capnproto/go-capnp, write a benchmark that calls goserbench.Bench{Marshal/Unmarshal and see commit-by-commit how the perf of the library is evolving as I refactor it.

While I personally think this would be beneficial, and goserbench specifically is (IMO) small enough that it wouldn't be a big issue having multiple modules on the same repo, I understand the rationale and will solve this issue in some other way.

alecthomas commented 3 months ago

Yes, I understood what the goal was. What I'm saying is that this pushes a not-insignificant amount of work onto this repo for a very minor advantage for upstream libraries, and I'm not willing to take on that work.

alecthomas commented 3 months ago

I do appreciate the thought though.