10BC0 Unify recursive update on ReplacementPane by hoxbro · Pull Request #4958 · holoviz/panel · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@hoxbro
Copy link
Member
@hoxbro hoxbro commented May 28, 2023

Fixes #4951
Fixes #4968

@codecov
Copy link
codecov bot commented May 28, 2023

Codecov Report

Merging #4958 (f97d028) into main (2ab34b3) will decrease coverage by 10.05%.
The diff coverage is 87.50%.

@@             Coverage Diff             @@
##             main    #4958       +/-   ##
===========================================
- Coverage   83.49%   73.44%   -10.05%     
===========================================
  Files         270      271        +1     
  Lines       38239    38281       +42     
===========================================
- Hits        31926    28116     -3810     
- Misses       6313    10165     +3852     
Flag Coverage Δ
ui-tests ?
unitexamples-tests 73.44% <87.50%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
panel/pane/base.py 86.17% <73.33%> (-0.92%) ⬇️
panel/tests/test_param.py 99.71% <100.00%> (+<0.01%) ⬆️

... and 57 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@philippjfr philippjfr changed the title Add _is_equal in ReplacementPane Unify recursive update on ReplacementPane May 28, 2023
@philippjfr philippjfr force-pushed the improve_equal_check branch from 888f7ad to 51e6a30 Compare May 28, 2023 17:13
@hoxbro
Copy link
Member Author
hoxbro commented May 28, 2023

I think it would be beneficial to have _generate_hash as a fallback and do the simple equally check first. Mainly because it _generate_hash is significantly slower for most cases.

Maybe even have a .all() try before using it.

@philippjfr
Copy link
Member
philippjfr commented May 28, 2023

My thinking was that in most cases the cost is neglible but in the case of a dataframe, where the cost does potentially matter significantly, simple equality won't, so you end up paying the cost twice.

@philippjfr
Copy link
Member

My thinking was that in most cases the cost is neglible but in the case of a dataframe where the cost does potentially matter significantly equal won't work anyway so you end up paying the cost twice.

The .all() could help with that. Not sure I prefer it though.

@hoxbro
Copy link
Member Author
hoxbro commented May 30, 2023

My thought was that we should not penalize every other type because Arrays and DataFrames are ambiguous with more than one element.

The .all is also faster than having to generate the hash.

@philippjfr
Copy link
Member

Fair points, swapped the order.

@philippjfr philippjfr merged commit aa9c6d7 into main May 30, 2023
@philippjfr philippjfr deleted the improve_equal_check branch May 30, 2023 08:56
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 10, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

2 participants

0