On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote:
On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev
wrote:
It will eventually zero in to commit-level accuracy after it's
been running for a while. I cleared the database as the last
time it was running, it was on another CPU, so the timings are
going to be different. (Still need to decide on a way to
measure execution time in some deterministic way.)
If you look at the vibe.d compile-time graph, you'll see
there's a 2.5s increase around Mid-2014. When I zoom in and
visit the commit, it's just a DDoc comment change
(https://github.com/dlang/phobos/pull/3542). I don't see how
that could account for the large increase in compile time.
The JS part of the project was adopted from somewhere else
(Mozilla's project for tracking Firefox performance), so it was a
bit hammered-on to the data schema we use here. Mozilla never
builds individual successive commits; you have to do it yourself
to zero in on a specific change. Because of this, the UI was
confusing and it wasn't obvious whether a commit is actually the
cause of a change in the metrics.
I've now changed it to only draw a line between two points if
they're adjacent in the git history. Still not perfect but
better. You can see this now by zooming into the big change in
e.g. "Empty program - compilation - peak heap size". (The vibe.d
one isn't resolved yet, give it a few days.)
The problem with representing this data is that we have the whole
commit list, which is nice and linear, but not all commits are
tested, and we can't graph untested commits because they
effectively don't have an Y value. There's also way too many
commits to draw at once, so it groups commits that occurred near
the same time together in one node, which again causes
complications when it's a mix of tested and untested commits.
(Currently it uses the median of the test results for tested
commits.)
More changes:
https://github.com/CyberShadow/TrenD/commits/master
