Support exporting to about:memory's JSON format about areweslimyet

[EricRahm]

This is semi-doable. As-is AWSY's format lacks 3 fields that every report entry has in about:memory:

• kind - this is problematic, it can be either NONHEAP, HEAP, or OTHER and is used by about:memory to figure out how to handle the data
• description - this probably doesn't matter, we can just empty string it or maybe omit it
• process - just dummy this out to "Main Process" (or maybe omit)

How do you see this actually working? Something like the :

1. click data point
2. choose a cset, click "view"
3. choose iteration
4. choose checkpoint
5. click "export"

[Nephyrin]

kind - this is problematic, it can be either NONHEAP, HEAP, or OTHER and is used by about:memory to figure out how to handle the data

We should probably be storing this :( It was added later and just not picked up.

Descriptions are less important, but might be convenient. Storing them in the DB probably isn't too hard since they change rarely, so just having a description lookup table similar to datapoints could work.

Units is another thing that was hacked on later, right now reporters are stored as "Foo/bar" for the bytes unit, but for things like percent we just prepend: "pct:foo/bar/..."

As for how this would work, yeah that sounds good. Maybe also stick a [export] next to [view] or something. We should grab a gzip-in-js library and just spin up a worker to reformat all the json and gzip it, then offer it up for download.

I also considered experimenting with how space-efficient just switching to storing all data as native .json.gz reports would be, but I don't see how it would be feasible.

[EricRahm]

It looks like we can hack around not having kind, if units != bytes then we can assume kind is other, if units == bytes then we can just flag it as heap. On the about:memory side we'll need to update the logic to handle if heap-unclassified is already present (that's the only usage of kind that cares whether it's heap or non-heap, and we already calculate it).

If we export from the [view] level we'll be exporting 30 memory reports, I'm not sure that's the usage we want. Also I haven't found a client side js-tar-gz library, so I don't think it's even really feasible at this point.

[Nephyrin]

The about:memory files are just json.gz, no tar needed, so I think just grabbing something like:
https://github.com/beatgammit/gzip-js Would work. It's probably also not too difficult to just emscripten gzip if no suitable libs exist!

Adding kind to the memory reports table and tweaking the testers to record it should be trivial, and we can use the heuristic you describe to work around it for old tests.

[EricRahm]

| The about:memory files are just json.gz, no tar needed
Sorry for the confusion, the tar part was if we wanted to export all 30 memory reports. gzip itself is definitely doable.

[Nephyrin]

Oh, gotcha -- for the [export] Thing I meant putting [export] next to every [view] link, so you options are to view a changeset or export it -- not export all 30 or whatnot.

[EricRahm]

That's the problem, each changeset has 30 memory reports associated with it (5 iterations, 6 checkpoints).

[Nephyrin]

Ohhh, right. Gotcha. Yeah, scratch that, in that case

[Nephyrin]

Resolved by pr #38