Add a compacting step at the end of profile sanitization

[mstange]

In the future we're planning to share more tables across threads, starting with the string table.

If a user wants to upload only visible threads, there's the risk of keeping data from other threads in the profile if more of that data is shared across threads.

So this commit adds a "compacting garbage collection" step before uploading, so that only data which is referenced within the sanitized profile is kept in the profile.

[codecov]

Codecov Report

Attention: Patch coverage is 90.14599% with 27 lines in your changes missing coverage. Please review.

Project coverage is 86.07%. Comparing base (d42d0f6) to head (28d9309).
Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
src/profile-logic/profile-compacting.js	90.14%	25 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5387      +/-   ##
==========================================
+ Coverage   86.03%   86.07%   +0.03%     
==========================================
  Files         312      313       +1     
  Lines       30352    30626     +274     
  Branches     8292     8339      +47     
==========================================
+ Hits        26114    26361     +247     
- Misses       3644     3669      +25     
- Partials      594      596       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[julienw]

It looks good to me and works well. I think that even today without sharing stringTable it already brings some privacy improvements, so thanks for that!

In the current state of the code, I find it difficult to follow what is writing to the various tables, vs what is merely reading.
In merge-compare I was making this more explicit by having as inputs the "readable" part and as outputs the "writable" elements. I'm not asking to do the same thing here, but at least you can add this information as comments to the various functions.

Optionally, sometimes you could change the parameters to make it clearer what a function needs as inputs (instead of passing all references and all translation maps always) and as outputs.

Thanks!

[mstange]

I found a problem: I'm changing the func table but I don't adjust the func indexes in the redux state. If you're focused on a function and then upload, you might end up focused on a different function.

[mstange]

To address the problem in my previous comment, I think I need to gather the set of functions which are referenced in the redux state first, then treat those functions as "used" and keep them around. And I need to provide a translation map in the redux action that replaces the unsanitized profile with the sanitized profile, so that any func indexes in the state can be adjusted.

I am not sure how to do the reverse translation if the user goes back to the original profile. Maybe we need to store a back-translation map next to where we store the original profile.

However, there is yet another issue: The translation maps are only valid for the raw thread. But if multiple threads are selected, and you focus a function in the merged "thread", then the state contains a function index into a funcTable which has been computed by merging multiple funcTables! I can't easily compute a translation map for a merged funcTable. We won't have this problem once there's only one funcTable across all threads, but I can't think of anything I could do before then.

Here's what I'm planning to do:

• I will change this PR to only compact the string table. There are no string indexes in the redux state, so this will solve the known issues of this PR.
• After this lands, I will make a PR which implements the format change to share the string table only.
• In a future PR for sharing all tables (except samples and markers), I'll have a commit which will expand this compaction step also apply to the other tables, and because merged threads will have the same funcTable as raw threads, it'll be easy to apply the translation maps to the redux state.