Skip to content

Conversation

hinto-janai
Copy link
Contributor

@hinto-janai hinto-janai commented Mar 28, 2024

Part 18

#97 <- Previous Next -> #101

Implements a standalone binary in database/benchmark/ that solely:

  1. Pulls in cuprate-database
  2. Tests/benchmarks all backends and various functions on the local machine
  3. Prints out info in {JSON, tables, txt, etc}

Currently compiled under the workspace as target/{debug,release}/cuprate-database-benchmark[.exe].

@Boog900
Copy link
Member

Boog900 commented Mar 30, 2024

Would something like criterion be helpful instead of making something custom?

@SyntheticBird45
Copy link
Member

Would something like criterion be helpful instead of making something custom?

Last time we wanted to test out read_from visitor pattern vs to_le_bytes, we used criterion and I find it exceptionally precise. Iirc it can also use black_box to verify implementation speed while ignoring optimization.

@hinto-janai
Copy link
Contributor Author

Using criterion means benchmarking will be limited to cargo bench [...] instead of being a standalone binary anyone can run, right? I'm not too familiar with criterion so I'm less certain I can finish this PR in time with the feature set I had planned.

I will switch to it though, it makes more sense.

@SyntheticBird45
Copy link
Member

SyntheticBird45 commented Mar 31, 2024

Using criterion means benchmarking will be limited to cargo bench [...]

AFAIA, It uses cargo bench indeed. If providing a binary is a necessity, then criterion we should forget.

I'm not too familiar with criterion so I'm less certain I can finish this PR in time with the feature set I had planned.

I haven't followed the prs but if boog's proposal was about simplifying the work by using a crate, then I'm afraid it'll result in the opposite. If nanosecond/microsecond accuracy is the priority then criterion should be used, otherwise I suppose a custom benchmark might be quicker to build up.

@Boog900
Copy link
Member

Boog900 commented Mar 31, 2024

Is there a reason we need a standalone binary?

I'm less certain I can finish this PR in time with the feature set I had planned

I mean how much will this slow us down and what features were you thinking of? This is not necessary so I don't think we are under any rush, but at the same time if you think a standalone binary is a better fit then sure.

simplifying the work by using a crate

It was also about simplifying the code, for a standalone binary we need to add command line handling etc, whereas cargos built in bench command + criterion could handle this and a lot more.

I also plan to use criterion in other parts of the code btw.

@SyntheticBird45
Copy link
Member

then criterion we should use

@hinto-janai hinto-janai changed the title database: benchmark/ binary database: benchmark/ Apr 20, 2024
@hinto-janai hinto-janai added A-storage Area: Related to storage. A-benches Area: Related to benchmarks. labels May 27, 2024
hinto-janai added a commit to hinto-janai/cuprate that referenced this pull request Oct 21, 2024
@hinto-janai
Copy link
Contributor Author

Replaced by #324.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-benches Area: Related to benchmarks. A-storage Area: Related to storage.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants