-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Convience script to run benchmark #1578
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This pull request was exported from Phabricator. Differential Revision: D53632438 |
b3d6bdf
to
03ae7bc
Compare
This pull request was exported from Phabricator. Differential Revision: D53632438 |
This pull request was exported from Phabricator. Differential Revision: D53632438 |
03ae7bc
to
95b790d
Compare
95b790d
to
74dda13
Compare
This pull request was exported from Phabricator. Differential Revision: D53632438 |
74dda13
to
0d1c475
Compare
This pull request was exported from Phabricator. Differential Revision: D53632438 |
0d1c475
to
0f53b6c
Compare
This pull request was exported from Phabricator. Differential Revision: D53632438 |
Summary: In addition to all the state that gets set on the node that is easy to serialize - like floats, enums, bools, etc - we also need to serialize measure functions. This is because these functions take a nontrivial amount of time up during layout and we should capture that. Also, they are important to the ability to truly replay layout as it was captured as the results of the measure functions determine many of the steps the layout algorithm takes. Capturing this is rather tricky however, but I think I found a solution that is relatively simple and non-error prone. Essentially, since we are capturing the entire tree and virtually every input that goes into the flexbox algorithm, we *should* be able to replay layout exactly as it was captured. This means that the order in which measure functions are called *should* be the same. If this is the case, then all we need to do to capture the measure functions is store their input, output, and duration in a big array. During deserialization we just keep track of an index and use that to determine which measure function we should call. That is the premise behind what happens in this diff. In theory the algorithm could change and the capture would be wrong but it is easy enough to recapture again. Additionally we need to dirty the tree so that we get rid of caching which might omit some measure func calls In order to capture you need to insert a method exposed by CaptureTree.h into the client measure func, which is kind of annoying but not that bad. In future diffs I will put a macro in place to make this even easier. I also add our first capture! Which is of a large react native desktop app Reviewed By: NickGerleman Differential Revision: D53581121
Summary: You need to provide the benchmark binary with a path to the captures. This is annoying and there is not a great way to do this in c++ that is cross-plat. So I just made this bash script to ease it. It can do buck and cmake. Reviewed By: NickGerleman Differential Revision: D53632438
0f53b6c
to
39de388
Compare
This pull request was exported from Phabricator. Differential Revision: D53632438 |
Summary: You need to provide the benchmark binary with a path to the captures. This is annoying and there is not a great way to do this in c++ that is cross-plat. So I just made this bash script to ease it. It can do buck and cmake.
Reviewed By: NickGerleman
Differential Revision: D53632438