| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch constitutes a slightly different and also simpler
approach to computing the performance index.
The hierarchical index structure is gone for now,
and the index is computed essentially like this:
1: Specify a base timestamp BT.
2: Specify a set of evaluation timestamps ET.
3: Specify a window size for median smoothing.
4: Specify a set of filters to effectively narrow
down the set of result histories that may contribute
to the index (there are currently five separate filters:
metric, platform, host, branch, and test case.
Zero or more values may be specified for each one).
5: Evaluate the index at a given evaluation timestamp ET(i) by
taking the arithmetic mean of the differences between the
values at ET(i) and BT for the individual result histories.
Both values are median-smoothed using a right-aligned window.
|
| |
|
|
|
|
|
|
|
|
|
| |
The result table is now indexed on
(bmcontextId, timestamp) which speeds
up fetching a time series that
doesn't need the snapshot, typically:
SELECT timestamp, value FROM result \
WHERE bmcontextId=... \
ORDER BY timestamp ASC;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the timestamp attribute from
the snapshot table to the result table. This
is done for two purposes:
1) Retrieving a pure result history (not including the
SHA-1 values) becomes quicker, since a join is avoided
(simply fetch all (timestamp, value) pairs matching a
given BM context).
2) It constitutes the first of two steps towards supporting
multiple result recordings per (SHA-1, BM context)
combination (the other step will be to remove the current
uniqueness constraint on that combination!).
The (future) use case is to improve statistical confidence
by e.g. taking the median value of the set of values for
a certain (SHA-1, BM context) combination as the representative
value for the combination.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more commands.
It turned out that we need to keep a time series
of index trees for the performance index after all:
There will be one base index tree (at timestamp -1, i.e.
older than any result), and one index tree for the
timestamps where the current index tree was changed
(i.e. essentially one or more result histories and/or
sub-indexes added or removed).
The index is evaluated on the basis of
the closest index tree earlier than the requested
evaluation time. This ensures that the correct
history constants are used. (The history constants
in turn ensure continuity of the index values
upon adding or removing result histories and/or
sub-indexes).
The following bmclient commands are implemented so far:
- index set base - sets the index base from an XML file
- index get tree - lists a certain index tree as XML
- index get names - lists the available index names
- index get values - evaluates an index at a set of timestamps;
dumps the result to stdout
- index get plot - same, except the result is plotted in an image
- get result - verifies a result ID in the XML file
|
| |
|
|
|
|
|
|
| |
There is no need to keep a time series of index trees.
Computing the index value will always be based on the state
of the single index tree (provided that the specified index
exists in the tree and none of the contributing baseline results
are yonger than the specified timestamp).
|
| |
|
|
|
| |
The performance index support does not work yet.
It remains to implement the functions in indextree.cpp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most important change of this patch
is a restructring of the database schema
in order to better support current
and future use cases.
In particular, the 'result' table has been reduced
in size (which is important since this table is
the one that will grow on a regular basis), and
a 'bmcontext' table has been introduced as an extra
structural level that is expected to make certain
queries faster than they would have otherwise been
(due to reduced need for complex join expressions
etc.).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The context part of the configuration of
a benchmark summary page may be interactively
manipulated using HTML <select> menus for
the individual components (metric, platform,
host, and branch). This patch both speeds up
the interactive selection and fixes a bug
that caused the selection from going haywire
(due to improper handling of asynchronous
communication).
This patch also involves a small visibility
change: Rather than just hiding the
non-matching options in each menu, all
available values are now shown, but only
the matching ones are selectable
(i.e. enabled.). WARNING: Manipulating
the disabled attribute of an <option>
element doesn't seem to be supported by
all web browsers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The bmserver now checks if the BMDISKWRITESYNC
environment variable is set to 'off', in which
case disk writes are no longer synchronous. This
speeds up database insertions and updates, but
the database may be corrupted if the OS crashes
in the middle of a write operation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most important change of this commit is that the
'iterations' component of the result value is gone.
Now the result value represented by just the
final real-valued result, rather than two integer
components: (accumulated) result and number of
iterations.
NOTE: The old file format is still accepted,
and when an iterations component is present, the result
component will be divided by this one.
The other significant change of this commit is that
indexes are added to the database scheme to speed up
queries. This only affects the 'initdb'
command-line option, though.
|
| | |
|
| |
|
|
|
|
|
| |
SQL defines INTEGER as 32-bit and BIGINT as 64-bit.
SQLite uses dynamic typing, so it doesn't matter, but
later we would like to replace SQLite with e.g. PostgreSQL,
so now we have reduced the risk of surprises.
|
| | |
|
| |
|
