Repository navigation
Conversation
| }) | ||
| for branch, rev in branch_heads.get(proj.id, []): | ||
| for exe in Executable.objects.filter(project=proj): | ||
| if (exe.id, rev.id) not in benchmarked: |
Member
There was a problem hiding this comment.
Hmm, this drops an executable unless it has results at exactly the branch's head revision, so it could also catche live executables and not just dead pairs. If I understand this correctly, if one executable's build fails for a night, its "latest" entry disappears until the next success, even though it has results one revision back?
Author
|
Closing, I solved the problem by reusing the same ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The comparison sidebar's executable section is built by
getcomparisonexes, which emits the full cross product of a project's executables with its tagged revisions and untagged branch heads: executables × (tags + head) entries. Nothing in the schema records which executable was built at which revision, so every pair is offered. Many of those combinations were never benchmarked. Adding a second executable to a project doubles its entry count.Result is the only source of truth for which pairs exist, so this PR looks them up once
(one extra query per page) and drops any pair with no results. On speed.pypy.org that takes the sidebar from 144 entries to 124. On speed.python.org nothing changes: each
project there has a single executable and no tagged revisions, so no pair was ever dead.
I noticed this when I added a new cpython executable, suddenly there are a lot of entries that don't make sense.