Support for Papyrus profiling

[xieve]

I've hacked together a parser/converter from Bethesda's proprietary Papyrus profiling format to speedscope JSON. There is no documentation of the format that I know of, but it isn't complex, parsing & converting takes around 100 LOC. It's a very niche format, but if you're interested, I could implement it natively into speedscope in a PR. Otherwise, I'd probably self-host a fork for the community.

So far, I've tested it with Skyrim, but FO4 profiles should work too.

[jlfwong]

Hi @xieve!

Happy to take it provided that...

1. It doesn't require bringing in any large dependencies or cause performance problems elsewhere (by e.g. being expensive to detect what kind of profile it is)
2. You're comfortable being a point of contact for changes needed to it
3. You're able to write tests for it to ensure it doesn't break over time

[xieve]

1. It doesn't require bringing in any large dependencies or cause performance problems elsewhere (by e.g. being expensive to detect what kind of profile it is)

The file ending is .log, which is not used yet and unlikely to be used elsewhere. The contents are plain text and look like this:

Script_abc_runner_quest log opened (PC)
21171:PUSH:3053:1:abcRunnerQuest (24021278):abc_runner_quest..iAmInitialized
21171:POP:3053:1:abcRunnerQuest (24021278):abc_runner_quest..iAmInitialized
21171:PUSH:3053:1:abcRunnerQuest (24021278):abc_runner_quest..isInitInProgress
21171:POP:3053:1:abcRunnerQuest (24021278):abc_runner_quest..isInitInProgress

We can easily detect that header.

2. You're comfortable being a point of contact for changes needed to it

Absolutely.

3. You're able to write tests for it to ensure it doesn't break over time

I don't have any experience writing tests so far, but I'm familiar with the concept. I'll take a look at the docs.

Another issue to take note of: This profiler tends to output "malformed" data. Here are two examples I encountered while writing the parser:

at 1 open a
at 2 open b
at 3 close a
at 3 close b

at 1 close a
at 2 open b
at 3 close b

I wrote a heuristic algorithm that fixes these and possibly even worse cases. Alternatively, I could detect those cases and throw them out.

[jlfwong]

The file ending is .log, which is not used yet and unlikely to be used elsewhere. The contents are plain text and look like this:

Sounds good! If you look at https://github.com/jlfwong/speedscope/blob/741fdeb4278d7ba9bc2c78c70db4bb7a5d5e6d5d/src/import/index.ts#L92, you'll see that we do two passes on import: first using a filename heuristic, and then failing that, using a content heuristic. Given the niche nature of this, I'd suggest only doing the content heuristic, since I do think it's possible existing formats use a .log extension.

I don't have any experience writing tests so far, but I'm familiar with the concept. I'll take a look at the docs.

Yeah, take a look at how the snapshot tests work. See, for example https://github.com/jlfwong/speedscope/blob/main/src/import/bg-flamegraph.test.ts

Another issue to take note of: This profiler tends to output "malformed" data. Here are two examples I encountered while writing the parser:

Will leave this to your discretion, since I'd be routing any bug reports to you