We generate URLs that are too long for bit.ly in a profile with lots of threads

[mstange]

Example profile

When I click the permalink button on this profile, bit.ly returns {"status_code":500,"status_txt":"INVALID_URI","data":[]}, which probably means that it thinks the URL is too long. The length is almost completely due to the globalTrackOrder parameter.

[julienw]

Wow, this profile has so costly reflows (several seconds for me)!! Filed #1480 for this.

The length of this URL is 3195.

[julienw]

I sent an email to [email protected] about this.

[gregtatum]

For what it's worth, removing the track ordering feature would most likely fix this issue.

[mstange]

Hmm, good point.

[gregtatum]

Also, we have the uintArrayToString which we can use for better compression of the arrays of indexes. We are already using this for CallNodePaths.

[mstange]

We use uintArrayToString now. The original example in this issue has gone down from 3213 bytes to 232 bytes.

But with lots of threads and processes, we still get really long URLs.

New example profile

About half the bytes go into hiddenLocalTracksByPid and the other half goes into localTrackOrderByPid.

I can think of two improvements:

• To reduce the size of hiddenLocalTracksByPid, we could treat hidden processes specially and stop persisting their individual hidden threads in the URL: If a process is hidden, all of its threads are hidden. Re-showing the global track for the process would only show the main thread for that process and none of its other threads.
• To reduce the size of localTrackOrderByPid, we could omit the thread order from the URL if the process's thread order is the default thread order.