GitLab

Error messages were displayed when running the test

Thought this might help with performance (not sure it does)

When two traces are from the same allocation site, with the same target
type and the exact same list of methods, we only keep one.

We used groupby and then processed each group, so we can clear as we go.

The benchmarks didn't use the numberSamples and numberWarmups given
to the constructor

Relied on streams more instead of lists, trying to get faster running
of generated benchmarks

Removed double-generation of benchmarks

There is probably a better way, since some options are then
invalid

The benchmark part was too unstable...

Each traces is loaded, grouped, and benchmarks are created to
try each collection for each benchmarks, then suggestions
are created

Originally, when loading a trace, only one benchmark was created
but there's now a function to also generate benchmarks so that
we can run them and make comparisons

Changed the expected values to fit the new format for benchmark
identifiers

List.of() doesn't exist for java 8

Theres a test for running a benchmark based on a trace
and one from trace benchmarks loaded from a CSV data

The user is able to change the number of iterations
for measurement and warmup in SyntheticBenchmarkRunner

A trace with a different object ID and location should have a different
ID.

We check that the ids are indeed different if we generate
two benchmarks correctly

Removed double iteration over all benchmarks to build the list of
benchmark indexes.

Also fixed a broken switch statement.

Was necessary to enable serialization

The test writes benchmarks to memory and then reads them

Means that deserializing from memory is also possible

Black holes are not member of BCBenchmarkPackage anymore, they are
handled by the class running the benchmarks, and passed as an argument
to runBenchmark()

One function iterated two times over a stream, causing an error.

We want to have serializable benchmarks to avoid too much reloading when
running them with JMH

Streams are better for performance reasons apparently. They are also
more idiomatic than sequences

We used to have traces generated based on the allocation site, which
makes no sense. Now, we use the object id (column "id") to identify
the traces, so that a trace is created for each object in the program.

Running benchmarks from a file of traces should work as expected,
each type of benchmark is selected and the correct traces are ran.

(One problem might remain, which is loading too the trace file too many
times...)

A class for running benchmarks that involve a Set collection.