firefox-devtools
Consider targeting the latest version of the profile format in our in-tree importers
Currently, the ways that importers generate profiles are different for different importers:
- chrome.js and dhat.js target the latest version of the processed profile format, through the use of
data-structures.js. - linux-perf.js targets version 24 of the gecko profile format (this is quite recent, it was targeting version 4 before).
- art-trace.js targets version 11 of the gecko profile format.
There are pros and cons for each cases.
processed format or gecko format?
The processed format contains more tables that may be more cumbersome to populate. It also changes more often than the gecko format. But it's also more structured than the gecko format where some data is stored in simple strings with a specific format. Also because it's our pivot data it's also more natural to work with because we're used to it.
target a specific version or latest version?
Targeting the latest version might make more sense, because being in-tree, it's easy to search and replace and keep consistent code and structures across the codebase. However targeting a specific version moves the job of upgrading the profile data to latest version to upgraders. Once the code is written targeting some version we don't need to touch it anymore... unless we want to take advantage of newer capabilities of the newer versions (eg: using categories in the linux-perf importer).
┆Issue is synchronized with this Jira Task
Here's my opinion:
processed format or gecko format: The processed format is harder to generate not just because of the extra tables, but also because of the struct-of-arrays representation. For example you can't use map to convert an array of, say, samples into a SampleTable. But maybe we can make a reusable ProfileBuilder which makes this easier.
specific version or latest version: I think it's my fault that we target a specific version in some of our importers. I thought doing so would reduce the maintenance burden, but I see now how it backfired. So I've changed my opinion and I now think that we should always target the latest version, for the reasons you stated. Furthermore, we don't have Flow type definitions for earlier versions, so targeting the latest version allows for more static checks.
