Skip to content

Profiler RFC #51

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.

Sign up for GitHub

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

Merged
bvaughn merged 12 commits into from
Jul 25, 2019
+141 −0
Merged

Profiler RFC #51

Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
317e02a
Profiler RFC
May 22, 2018
dfe022f
Unresolved questions
May 22, 2018
58afaa1
Formatting nits
May 22, 2018
b529613
Organizational tweask
May 22, 2018
1475772
Added an async caveat about actual time
May 22, 2018
7cb55e6
Typofix
May 22, 2018
3e9edf1
Added clarfiication note about how <Profiler> works in production bundle
May 22, 2018
6062c52
Typofix
Jun 9, 2018
b1834f9
Renamed actualTime -> actualDuration and baseTime -> baseDuration
Aug 3, 2018
c263445
Updated note about Profiler experimental release
Aug 3, 2018
a5c38f4
Added interaction-tracking proposal to RFC
Aug 3, 2018
009a0b4
Udpated RFC
Jul 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Renamed actualTime -> actualDuration and baseTime -> baseDuration
  • Loading branch information
Brian Vaughn committed Aug 3, 2018
commit b1834f9f758c52b866e1d17d22a212634e2030dc
8 changes: 4 additions & 4 deletions text/0000-profiler.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,8 +71,8 @@ The `onRender` callback is called each time a component within the `Profiler` re
function onRenderCallback(
id: string,
phase: "mount" | "update",
actualTime: number,
baseTime: number,
actualDuration: number,
baseDuration: number,
startTime: number,
commitTime: number
): void {
Copy link

@j-f1 j-f1 May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not pass all of this as a single object so people can pick out the keys they need?

Copy link
Collaborator Author

@bvaughn bvaughn May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasonable question!

I'd say the reasons are that I'm following precedent (we don't pass named parameters anywhere else that I can think of off the top of my head) and avoiding allocating a wrapper Object during commit.

I'd be interested to hear what others think about this aspect.

Copy link

@jamesreggio jamesreggio May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd vote for an object, despite the fact that it breaks with existing React API precedent.

The order of these timing arguments is going to be tough to memorize, and I can imagine only being interested in a subset of them. Using an object also enables you to add additional timing data down the road.

I'd view it as somewhat analogous to an event object, which has a variety of keys, only some of which are of interest for any given listener.

Copy link
Member

@gaearon gaearon May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would you need to memorize it? I imagine you'd only use Profiler in a few places in the app, and each time could consult the docs.

The need to avoid allocations is pretty important because adding GC pressure can skew the profiling results.

Copy link
Collaborator Author

@bvaughn bvaughn May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if you use Profiler in more than one place, the callback you pass it is likely shared- (this is why the id parameter exists)- so you would only need to write these params (in the correct order) in a single place.

Copy link
Collaborator Author

@bvaughn bvaughn May 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, this concern makes sense. And I agree that we wouldn't be allocating too many new objects for this, because it would only be one per Profiler per commit. I was just sharing rationale for why it is currently the way it is.

Copy link

@alvaropinot alvaropinot Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just my personal opinion here, but an object looks good from my point of view as long functions with more that 2/3 args are always hard to remember, you tend to start adding null for the values that you might not want to use, I'm looking at you JSON.stringify(foo, null, 2) 😅 , you also need to remember the order and it's harder to refactor as you impact anyone already using that order.

Plus with the actual syntax for destructuring the function signature looks pretty much the same but with curly braces 😁, the best of two worlds!

onRenderCallback({ id, phase, actualTime, baseTime, startTime, commitTime })

vs

onRenderCallback(id, phase, actualTime, baseTime, startTime, commitTime)

Copy link

@jamesreggio jamesreggio Jun 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that the Profiling API is out in the 16.4.1 release, I assume you decided to take no action on this?

Copy link
Collaborator Author

@bvaughn bvaughn Jun 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The unstable_Profiler component was introduced in 16.4.0. The only thing that's new in 16.4.1 is a production+profiling build.

Unstable APIs can change. We haven't decided one way or another. This is kind of an open thread for discussion.

Copy link
Collaborator Author

@bvaughn bvaughn Jun 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just circling back on this particular thread. Sebastian and I chatted about this yesterday, and we've decided to avoid named parameters because the overhead of the wrapper objects (however small each individual one is) will add up in larger applications.

Expand All @@ -87,12 +87,12 @@ The `id` value of the `Profiler` tag that was measured. This value can change be
#### `phase: "mount" | "update"`
Either the string "mount" or "update" (depending on whether this root was newly mounted or has just been updated).

#### `actualTime: number`
#### `actualDuration: number`
Time spent rendering the `Profiler` and its descendants for the current (most recent recent) update. This time tells us how well the subtree makes use of `shouldComponentUpdate` for memoization.

Ideally, this time should decrease significantly after the initial mount. Althoguh in async mode, under certain conditions, React might render the same component more than once as part of a single commit. (In this event, the "actual" time for an update might be larger than the initial time.)

#### `baseTime: number`
#### `baseDuration: number`
Duration of the most recent `render` time for each individual component within the `Profiler` tree. This reflects a worst-case cost of rendering (e.g. the initial mount or no `shouldComponentUpdate` memoization).

#### `startTime: number`
Expand Down