scalars: commit chart changes in batch #4053
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
Summary: The data loader behavior maintains a fine-grained cache of key-value pairs. This is useful because when the set of requested keys expands, only the new keys need to be fetched. But, until now, the behavior has been hard-coded to fire a separate request for each key-value pair. Clients can have either fine-grained cache invalidation or efficient batched requests, but not both at the same time. This patch enriches the behavior to support just that. In a future change, the scalars dashboard will take advantage of this to batch requests for multiple runs and a single tag. In doing so, we need to shuffle around the API a bit. Instead of asking clients to provide `getDataLoadUrl: (Item) => string` plus a separate function `requestData: (url: string) => Promise<Data>` (where “`Item`” and “`Data`” are the keys and values, respectively), clients now provide a single function `requestData` that takes raw `Item`s (now plural), performs the request(s), and returns the data. The function provides a stream of key-value pairs, which is represented in callback style for convenience. (We don’t want to drag Observable into this.) The purpose of this approach, as opposed to a perhaps more natural approach that simply adapts `getDataLoadUrl` to return some kind of request struct with a callback to map a response into key-value pairs, is to accommodate the variety of existing clients. The structures get pretty wild: e.g., `tf-line-chart-data-loader` mixes in the behavior but doesn’t actually provide the needed properties; they’re provided instead by `tf-scalar-card`, but then `tf-hparams-session-group-details` further overrides some of those properties of `tf-scalar-card` with an entirely different backend. It’s a bit wordier for clients, but at least there are fewer moving pieces to keep track of. Test Plan: The scalars, custom scalars, distributions, histograms, and hparams dashboards all work. The fine-grained invalidation on the scalars dashboard works: e.g., set the tag filter to `mnist` and then to `mnist|hparams`, and watch only the hparams demo data load; then, set it to `hparams` and watch the MNIST charts disappear without any repaints to the hparams demo charts. The post-load callback properly causes scalar charts’ domains to adjust. The refresh button in the dashboard UI properly invalidates and re-fetches data. (Make sure to run with `TB_POLYMER3=1` until that’s the default.) wchargin-branch: dlb-batch-finegrained wchargin-source: 14ec8abde36c4563a4922209d361fc5bd16b6061
Summary: DO NOT SUBMIT until corresponding internal change is submitted. Test Plan: Manually tested; to be documented. wchargin-branch: scalars-mux-runs wchargin-source: 9459c8cc6bc0b041016dfc689306639a04080217
wchargin-branch: scalars-mux-runs wchargin-source: 2e1bd5c8cd3393ac0a79c64b0c87ea43bf346b8a # Conflicts: # tensorboard/plugins/scalar/polymer3/tf_scalar_dashboard/tf-scalar-card.ts
wchargin-branch: scalars-mux-runs wchargin-source: 2e1bd5c8cd3393ac0a79c64b0c87ea43bf346b8a
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
plugin:scalars
theme:performance
stephanwlee
approved these changes
Aug 19, 2020
wchargin-branch: scalars-mux-runs wchargin-source: 0484e726315d46c282c3d61994ffb9e4dc07c20b
wchargin-branch: scalars-batch-commit wchargin-source: 0b1f5cd089e6fcfeeb1cf0744ce98d7a70bf4740
wchargin-branch: scalars-mux-runs wchargin-source: a4ca83ea5bf6b665052c076df835592105e5eefb
wchargin-branch: scalars-batch-commit wchargin-source: b28108c936f43ba7cb072702e56a650e89d20c2f
wchargin-branch: scalars-batch-commit wchargin-source: 86b429e4f04ee981ee42c508d1f8ed813a04a26c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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