| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The 'from' time sample (i.e. the last smooth result
not later than the 'from' time) is included in the
range in which the 'zero' and 'max level difference'
instability conditions apply.
This patch also avoids a potential division by zero
(that would occur if the max- and min levels were not
found).
|
| | |
|
| |
|
|
|
|
| |
This covers the case where the user
unintentionally tries to compute the index or ASF stats
without having any filter values explicitly set.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
To determine whether a result history is unstable for the ASF stats,
the tests for zero values and max-min difference are now
applied only to results that are within the from..to time range.
|
| |
|
|
|
|
| |
The result history details page now shows more relevant
information, like the 'from' and 'to' times, the actual
samples to be picked, and the outliers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It was effectively (and wrongly!) assumed that at least one
contributing result history would have at least two
subsequences (of contiguous equal values). But this assumption
could easily be violated by setting the median window size
sufficiently high (so that all data was smoothed away!).
Cases like these are now handled and indicated as n/a.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The median smoothing now identifies and marks all
outliers in a result history the first time a smooth
value is requested. The outliers are the values that
were not selected at least once as the median value
when sliding the window. The smooth values are simply
the non-outliers.
This algorithm has the property of preserving the order
of the smooth values (simply since they are not moved
from their original positions at all!).
The old algorithm would effectively substitute each
value (except the first few ones which were
"uncomputable" because the window was right-aligned)
by its smoothest neighbor (possibly including itself).
In general, the ordering of the final smooth sequence
would then not match that of the original sequence.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
A negative index base time now corresponds to the last
contributing timestamp instead of the current time.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The index is now evaluated only at timestamps for which
at least one contributing result exist. These are the
exact timestamps at which the index may potentially
change the value.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1: The index itself is computed so that the _change_ in index value
between any two points in time indicates the average performance
increase during this time period in terms of a log2-based
difference. An index value _change_ of 1, 0, and -1 thus
indicates a doubled, unchanged, and halved performance respectively.
(The corresponding linear factors would be 2, 1, and 0.5.).
Note: Individual index values bear no useful meaning when regarded in
isolation. The graph is however shifted vertically so that each
individual index value indicates the change from the index value at the
given base time (the index value of the latter is then 0 and 1 in the
log2 and linear domain respectively).
2: Clicking on a particular data point in the index graph now opens a
page that shows the top-10 results histories that contributed most
significantly to this particular change in the index value.
Each contributor graph indicates the data points that were used for
computing the contribution for this index value.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This feature allows the user to select a benchmark
(i.e. a test case / test function / data tag combination)
and generate a plot of all the result histories generated
by this benchmark in different contexts.
This is is useful for manual correlation analysis (e.g.
a certain change in one context might also occur in
other contexts).
|
| |
|
|
|
|
| |
It is now possible to save, load, and delete
a performance index configuration (i.e. all the
settings in the 'Index' section in the BM web app).
|
| |
|
|
|
|
| |
It is more convenient to let the server sort the filter
values instead. Then the combination structure can be
based directly on the sorted values.
|
