-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
improve rerender of vz_line_chart #3524
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We identified few several expensive operations going on underneath Plottable. - When we modified dataset() attached to a plot, Plottable recalculated domain which in turn triggered redraw of the plot. - Plot redraw is scheduled but repeated `clearTimeout` and `setTimeout` take considerable time which was the large part of the dataset update - Changing a dataset caused us to updateSpecialDataset N times (N = number of runs) We addressed the issue by: - `commit` API after making all the changes - remember which runs/dataset were changed - update datasets only once per commit We did not address: - autoDomain recomputing the bounds on every data changes. - there is no programmatical way to disable auto domain unless we change the domain which causes, for instance, zoom level to reset Empirically, the render time: - toggling run on the selector went down from 1740ms to 273ms - triggering the log scale went down from 315ms to 264ms - from ~670ms to ~620ms when measured from mouse up Do note that this change does not improve time for other charting operation like zoom, smoothing changes, and etc...
Very nice. On the hparams demo’s |
bmd3k
approved these changes
Apr 22, 2020
wchargin
added a commit
that referenced
this pull request
Apr 27, 2020
wchargin
added a commit
that referenced
this pull request
Apr 27, 2020
Summary: This reverts commit 27d0023, then reinstates stubs for the new method definitions due to Google-internal code that expects them to exist. Stopgap for #3551 pending real fix. Test Plan: Opening the PR curves dashboard and sliding one of the step sliders now correctly renders the PR curve instead of showing just the final datum. wchargin-branch: revert-3524
caisq
pushed a commit
to caisq/tensorboard
that referenced
this pull request
May 19, 2020
We identified few several expensive operations going on underneath Plottable. - When we modified dataset() attached to a plot, Plottable recalculated domain which in turn triggered redraw of the plot. - Plot redraw is scheduled but repeated `clearTimeout` and `setTimeout` take considerable time which was the large part of the dataset update - Changing a dataset caused us to updateSpecialDataset N times (N = number of runs) We addressed the issue by: - `commit` API after making all the changes - remember which runs/dataset were changed - update datasets only once per commit We did not address: - autoDomain recomputing the bounds on every data changes. - there is no programmatical way to disable auto domain unless we change the domain which causes, for instance, zoom level to reset Empirically, the render time: - toggling run on the selector went down from 1740ms to 273ms - triggering the log scale went down from 315ms to 264ms - from ~670ms to ~620ms when measured from mouse up Do note that this change does not improve time for other charting operation like zoom, smoothing changes, and etc...
caisq
pushed a commit
to caisq/tensorboard
that referenced
this pull request
May 19, 2020
tensorflow#3552) Summary: This reverts commit 27d0023, then reinstates stubs for the new method definitions due to Google-internal code that expects them to exist. Stopgap for tensorflow#3551 pending real fix. Test Plan: Opening the PR curves dashboard and sliding one of the step sliders now correctly renders the PR curve instead of showing just the final datum. wchargin-branch: revert-3524
caisq
pushed a commit
that referenced
this pull request
May 27, 2020
We identified few several expensive operations going on underneath Plottable. - When we modified dataset() attached to a plot, Plottable recalculated domain which in turn triggered redraw of the plot. - Plot redraw is scheduled but repeated `clearTimeout` and `setTimeout` take considerable time which was the large part of the dataset update - Changing a dataset caused us to updateSpecialDataset N times (N = number of runs) We addressed the issue by: - `commit` API after making all the changes - remember which runs/dataset were changed - update datasets only once per commit We did not address: - autoDomain recomputing the bounds on every data changes. - there is no programmatical way to disable auto domain unless we change the domain which causes, for instance, zoom level to reset Empirically, the render time: - toggling run on the selector went down from 1740ms to 273ms - triggering the log scale went down from 315ms to 264ms - from ~670ms to ~620ms when measured from mouse up Do note that this change does not improve time for other charting operation like zoom, smoothing changes, and etc...
caisq
pushed a commit
that referenced
this pull request
May 27, 2020
Summary: This reverts commit 27d0023, then reinstates stubs for the new method definitions due to Google-internal code that expects them to exist. Stopgap for #3551 pending real fix. Test Plan: Opening the PR curves dashboard and sliding one of the step sliders now correctly renders the PR curve instead of showing just the final datum. wchargin-branch: revert-3524
wchargin
added a commit
that referenced
this pull request
Aug 19, 2020
Summary: In #3524, we defined a batch API for chart updates to avoid useless paints that would be immediately overwritten. We now take further advantage of this API to only paint charts once all data has been loaded. Test Plan: On the hparams demo directory, this brings paint time (post-network) for four charts rendering 50 trials each down from about 8 seconds to under 1 second. wchargin-branch: scalars-batch-commit wchargin-source: b0babe18b592f577803eebe6f4102c032fc9246f
wchargin
added a commit
that referenced
this pull request
Aug 20, 2020
Summary: In #3524, we defined a batch API for chart updates to avoid useless paints that would be immediately overwritten. We now take further advantage of this API to only paint charts once all data has been loaded. Test Plan: On the hparams demo directory, this brings paint time (post-network) for four charts rendering 50 trials each down from about 8 seconds to under 1 second. wchargin-branch: scalars-batch-commit
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We identified few several expensive operations going on underneath Plottable.
domain which in turn triggered redraw of the plot.
clearTimeout
andsetTimeout
take considerable time which was the large part of the dataset update
number of runs)
We addressed the issue by:
commit
API after making all the changesEmpirically, the render time:
Do note that this change does not improve time for other charting
operation like zoom, smoothing changes, and etc...
Test plan: rendered the temperature demo and manually clicked around UI elements and compared the result against TensorBoard 2.1.1.