By looking over this graph, you can notice raptor-tp6m-wikipedia-geckoview opt originating from an Android PGO-like platform.

I need someone to explain the story behind these platform names. Why did we have to change their name?
I believe we created the option field for situations like these: to specify things like build type and not hard code it in other places. (If it's still needing some tweaking, do share this.)

At the moment, these kind of metrics are confusing not only for developers, but Perf sheriffs alike.

Joel, if you have more context on this matter, could you provide some insights? I looked over bug 632954, but didn't quite get it.

we finally have the ability for pgo builds on android. Our systems are setup that if we make a change to a config or build that we have a unique signature and platform in treeherder. This helps avoid confusion when asking questions "why is there a big change here". While it might be obvious now there was a change 2 weeks ago that was opt->pgo, it wouldn't be obvious in 3 months.

PGO is a whole new build type vs traditional opt builds, we have always built both side by side and given our volume limitations we expect to run only on PGO for perf. OSX will switch to PGO in the coming weeks, then we still need windows/aarch64 and android/aarch64 to be PGO.

Can you not see the difference in the platform name?

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #1)

Can you not see the difference in the platform name?

I do see the difference in the platform name: it added the -pgo suffix to the old android-hw-g5-7-0-arm7-api-16 name.
I was hoping that for new measurements like these I would have seen raptor-tp6m-wikipedia-geckoview pgo originating from same android-hw-g5-7-0-arm7-api-16 platform (which is now capable of doing PGO builds).

we have opt/debug/asan as build config optoins, pgo is being treated as a platform difference, so pgo is used in the platform name. That is how we have always done it, I am not sure why this is more confusing now except this is the first time we have enabled PGO for a new platform in many years. Despite saying this is how we have always done it, that doesn't mean it is the right thing to do, although changing things to be platform/config where config = [pgo, debug, opt, asan, ccov, shippable] could be more challenging to implement.

Regarding Perfherder, it would be ideal to have pgo/shippable as build config options, alongside the existing opt/debug/asan. It would ease the reading of perf alert signatures + the searches we perform for loading specific measurements into our dashboards.

that would be a much larger change, we can file a bug or make this part of that, but I suspect it will be a wontfix or treated low priority. There are a lot of moving parts to consider in making that happen. How is this a problem now and wasn't a problem before?

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #5)

that would be a much larger change, we can file a bug or make this part of that, but I suspect it will be a wontfix or treated low priority. There are a lot of moving parts to consider in making that happen. How is this a problem now and wasn't a problem before?

We adapted to the old problems on the fly. For example, it's understandable why we receive OPT-like measurements from shippable-configured platforms.
But the variation from this case brought some extra confusion for other people reading the dashboards: the fact that we got OPT-like measurements (which are actually PGO) originating from PGO-enabled platforms. It's an ambiguous situation and a reader wouldn't know which signature part to trust: the build config or the platform name?