[UI] Reduce complexity of isEmptyChartCard in RunsCharts rendering#20488
[UI] Reduce complexity of isEmptyChartCard in RunsCharts rendering#20488serena-ruan merged 1 commit intomlflow:masterfrom
Conversation
🛠 DevTools 🛠
Install mlflow from this PRFor Databricks, use the following command: |
|
Documentation preview for 26a3d33 is available at: More info
|
cc441b1 to
ad9ec91
Compare
|
Thanks @mdalvz0000 ! The implementation looks solid, for the screen recording you shared could you attach before v.s after so it's more visible about the performance change? |
Thanks, I just added the "Before" video to the description. |
d405c86 to
ad9ec91
Compare
… and RunsChartsDraggableCardsGridSection Signed-off-by: Malcolm Alvarez <mdalvz@amazon.com>
ad9ec91 to
26a3d33
Compare
|
Hi @hubertzub-db could you take another look at this? if it's good would like to merge it :D |
hubertzub-db
left a comment
There was a problem hiding this comment.
lg!
OOC: do you have any metrics about the performance improvement? 🙂
|
I don't have specific metrics, but the above before / after configuration can be achieved with an experiment containing runs with 8000 unique metrics. |
…lflow#20488) Signed-off-by: Malcolm Alvarez <mdalvz@amazon.com>
…lflow#20488) Signed-off-by: Malcolm Alvarez <mdalvz@amazon.com>
…20488) Signed-off-by: Malcolm Alvarez <mdalvz@amazon.com>
Related Issues/PRs
What changes are proposed in this pull request?
This commit optimizes the performance of empty chart detection in RunsCharts when dealing with high metric counts. It introduces a predicate factory pattern that pre-computes which metrics are available across runs once, then reuses that information when evaluating multiple charts. The implementation replaces expensive array operations with efficient Set-based lookups, significantly reducing redundant computation when filtering large numbers of chart cards.
How is this PR tested?
Before:
Before.mp4
After:
Big1_small.mp4
Does this PR require documentation update?
Release Notes
Is this a user-facing change?
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverHow should the PR be classified in the release notes? Choose one:
rn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionShould this PR be included in the next patch release?
Yesshould be selected for bug fixes, documentation updates, and other small changes.Noshould be selected for new features and larger changes. If you're unsure about the release classification of this PR, leave this unchecked to let the maintainers decide.What is a minor/patch release?
Bug fixes, doc updates and new features usually go into minor releases.
Bug fixes and doc updates usually go into patch releases.