Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make URLs shareable #75

Open
4 tasks
taneliang opened this issue Jul 20, 2020 · 0 comments
Open
4 tasks

Make URLs shareable #75

taneliang opened this issue Jul 20, 2020 · 0 comments
Labels
importance: 3 - good to have Stretch goal - a dream that we likely will not have the resources to implement urgency: 4 - no urgency We have an indefinite amount of time to complete this work type: implementation A task that primarily involves bashing code work type: investigation A task that primarily involves digging into a particular problem

Comments

@taneliang
Copy link
Member

taneliang commented Jul 20, 2020

From Brian's 17 July email and doc:

Make URLs shareable (like Firefox profiler)

  • Full JSON profiles are huge, but also contain mostly data that we aren’t using. Maybe we can serialize the parts we do use (React’s profiler marks, JS flame graph) and store it on the URL like Mozilla does? (If we could get it below the max 2MB size limit at least).

Steps

  • Figure out what can be removed. Ensure that all User Timing data is retained for Show remaining User Timing marks in the UI  #72.
  • Figure out how this can also work with Firefox support (Add Firefox support #52)
  • Figure out a way to get it below 2MB. Verify with an average profile?
  • Implement a URL import route (we may want to add react-router instead of implementing a state-based route like we do now)

Update 20 Jul 2020:

Maybe we should also consider storing profiles in local storage? Ruled out by Brian.

Moved to the back in terms of priority, improving on the MVP from feedback takes precedence.

Update 06 Aug 2020:

Using the facebook.com profile, JSON.stringify(profilerData).length = 58,488,710

Here are some strategies I can think of to reduce this size:

  • Serialize the data with shorter keys.
  • Compression: will be able to significantly reduce the size by a few times, but I'm quite sure we won't be able to get it to <2k chars
  • Replace JSON with a more compact transmission format
  • Dump some displayed information such as component stacks and script URLs.
  • Dedupe flamechart information: many flamechart frames are executions of the same underlying node.

Here is a wild alternative to this exact feature that I can think of: implement a one-click way to upload profiles as a GitHub Gist/Pastebin, coupled with a one-click way to import gists and pastes.

@taneliang taneliang added urgency: 4 - no urgency We have an indefinite amount of time to complete this importance: 2 - should have This should be implemented, but we will still have a working product if we don't work type: investigation A task that primarily involves digging into a particular problem work type: implementation A task that primarily involves bashing code labels Jul 20, 2020
@kartikcho kartikcho added importance: 3 - good to have Stretch goal - a dream that we likely will not have the resources to implement and removed importance: 2 - should have This should be implemented, but we will still have a working product if we don't labels Jul 20, 2020
taneliang added a commit that referenced this issue Jul 28, 2020
… frame type

Lays groundwork for #75 by reducing the flamechart data passed around
the app.

Was also intended to help #50 by moving some division operations from
the hot render loops into preprocessFlamechart, but any performance
gains are negligible.

* `yarn flow`: no errors in modified code
* `yarn lint`
* `yarn start`: no performance difference
taneliang added a commit that referenced this issue Jul 29, 2020
… frame type

Lays groundwork for #75 by reducing the flamechart data passed around
the app.

Was also intended to help #50 by moving some division operations from
the hot render loops into preprocessFlamechart, but any performance
gains are negligible.

* `yarn flow`: no errors in modified code
* `yarn lint`
* `yarn start`: no performance difference
taneliang added a commit that referenced this issue Jul 29, 2020
… frame type

Lays groundwork for #75 by reducing the flamechart data passed around
the app.

Was also intended to help #50 by moving some division operations from
the hot render loops into preprocessFlamechart, but any performance
gains are negligible.

* `yarn flow`: no errors in modified code
* `yarn lint`
* `yarn start`: no performance difference
taneliang added a commit that referenced this issue Jul 29, 2020
… frame type

Lays groundwork for #75 by reducing the flamechart data passed around
the app.

Was also intended to help #50 by moving some division operations from
the hot render loops into preprocessFlamechart, but any performance
gains are negligible.

* `yarn flow`: no errors in modified code
* `yarn lint`
* `yarn start`: no performance difference
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
importance: 3 - good to have Stretch goal - a dream that we likely will not have the resources to implement urgency: 4 - no urgency We have an indefinite amount of time to complete this work type: implementation A task that primarily involves bashing code work type: investigation A task that primarily involves digging into a particular problem
Projects
None yet
Development

No branches or pull requests

2 participants