A workflow that would benefit many who push to try and test perf fixes would be to push to try and easily see in a compare view (or simplified view with alerts) the new push vs the base revision. While you can pull up a base revision easily in perfherder, it might not have any data or only a single data point. Right now it is easier to just push two pushes to try and then compare the data. Some of this can be done via education to show how to find a job and retrigger a job- but I think the process of finding the right branch/revision/job is daunting and we could make it better. Maybe a |./mach try fuzzy -perfcompare -q 'damp'| where -perfcompare will bring up a URL with the base revision and the job highlighted, then you can just click the retrigger button a few times, or it brings you to treeherder where we have a custom action that triggers the jobs we need. I think we can limit this to a single job (i.e. talos-damp or talos-other) instead of worrying about multiple tests regressing across multiple jobs/platforms.

(In reply to Joel Maher ( :jmaher ) (UTC+2) from comment #0) > Right now it is easier to just push two pushes to try and then > compare the data. Yes, we very frequently do that, leading to more try jobs for little reason. Sometimes you may use the "compare against last X days of your base branch", but anytime it reports a regression/improvement, you push a custom base run to ensure this isn't related to recent changes over the last X days. And in many cases, it is just easier to immediately push a custom base revision when you are expecting significant perf changes. > Some of this can be done via education to show how to find a job and > retrigger a job- but I think the process of finding the right > branch/revision/job is daunting Yes. You may also add the git to hg sha conversion in the way when you are using git cinnabar. > and we could make it better. Maybe a > |./mach try fuzzy -perfcompare -q 'damp'| where -perfcompare will bring up a > URL with the base revision and the job highlighted, then you can just click > the retrigger button a few times, or it brings you to treeherder where we > have a custom action that triggers the jobs we need. My dream would be to have a link leading to the compare view, with base and new changesets pre-filled. Then from this page, you may have buttons to run more talos/damp runs. > I think we can limit this to a single job (i.e. talos-damp or talos-other) > instead of worrying about multiple tests regressing across multiple > jobs/platforms. Regarding DevTools, it makes sense we only ever look at one platform at a time and only DAMP.