Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmark parameters #229

Open
str4d opened this issue Aug 24, 2017 · 3 comments
Open

Benchmark parameters #229

str4d opened this issue Aug 24, 2017 · 3 comments

Comments

@str4d
Copy link
Contributor

str4d commented Aug 24, 2017

The current codespeed model supports two kinds of groupings for benchmarks:

  • Environments (running the same benchmark under different conditions)
  • Parents (organising benchmarks into hierarchies, e.g. having a parent benchmark which itself is an aggregation of sub-benchmarks)

In my own use of codespeed, I'm finding that I want to write a particular benchmark, and then run it under various conditions within the same environment. Examples:

  • Running a benchmark with 1 vs 2 threads
  • Measuring the time to create a Zcash transaction when the wallet has 100k coins vs. 200k coins

Currently I've been implementing these as separate benchmarks, but this uses up a lot of UI space, and doesn't convey the relationship between them. Parents are not sufficient either, as there isn't a parent benchmark as such, just a group of siblings.

I think a better model for representing these would be for a Result to specify a set of Parameters for the Benchmark it is using. Moving from this:

Result ------------------------------> Benchmark

to something along these lines:

Result ------------------------------> Benchmark
   \                               /
    \--> Value -----> Parameter --/
                  /              /
    /--> Value --/              /
   /                           /
Result -----------------------/
@str4d
Copy link
Contributor Author

str4d commented Aug 25, 2017

Here are the properties I'd like to see in this setup:

  • A Benchmark may have zero or more Parameters.
  • A Result must specify a value for each Parameter of its Benchmark.
  • If the Benchmark for a Result does not exist, when it is automatically created its Parameters are also created if the Result specifies them.
  • For sanity, a Result cannot automatically add a Parameter to a Benchmark; the admin must manually create the Parameter first, specifying a corresponding value for all existing Results (which implicitly were all using the same value for that previously-unspecified Parameter).

I can see two ways to implement this, with competing trade-offs:

  • Create a Parameter model with a Benchmark ForeignKey, and add a ManyToManyField(Parameter) to Result, using a ParameterValue intermediate model to store the value.
    • Makes it easy easier to enforce that a Result specifies a single value for every Parameter.
      • Django doesn't support unique_together for ManyToManyFields, so that would need to be replaced entirely with a custom uniqueness check. This would be the case for both implementation options.
    • Makes it a bit harder to collect all Results with the same value.
    • IMHO it is semantically weaker. A Parameter value is not IMHO a property of a Result; rather it is a property of the test setup (like Environment is), and thus should be a logical object that multiple Results can reference.
  • Create a Parameter model with a Benchmark ForeignKey, and a ParameterValue model with a Parameter ForeignKey. Add a ManyToManyField(ParameterValue) to Result.
    • Makes it easy to collect all Results with the same value.
    • Makes it more complex to enforce that a Result specifies a single value for every Parameter.

@str4d
Copy link
Contributor Author

str4d commented Aug 25, 2017

I'm going to proceed with implementing this using a ParameterValue model, given that the upsides to the other approach are minimal.

@tobami
Copy link
Owner

tobami commented Aug 26, 2017

Going for the second option probably makes sense. However, this probably warrants some discussion. You brought up quite an important topic actually. Some heavy users of Codespeed were hitting it's limitations when wanting to store and compare results with many different "attributes" (your parameters) attached, and discussed possible implementations in their own companies. Have a read:
https://groups.google.com/forum/#!topic/codespeed/liOwjr_uzbg

So I see this as the start of Codespeed 2.0, this is good thinking. Would you like to start a discussion thread there? We might want to outline a roadmap where Codespeed 1.0 is released, and then we restructure the project around parameters/attributes. Of course incremental approach is also an option, only before adding more and more features a bit of restructuring would do well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants