One possible performance concern may be dropping and re-creating large GUI (or framework—aka GUI Easy) objects with each state change. I think in particular the objects produced by dyn-view and similar conditional views may be redoing too much work when the (often derived) state they hasn't changed value but signals a change (often due to a change in a sibling branch of the state).
Does GUI Easy already do some caching[^1] here? If not, is that something I can experiment with locally without forking (e.g., by creating my own dyn-view &co. that do what I need)? [And if so, must this be at the OO layer or can it be done at the functional layer?]
Or is something I must contribute upstream?
[^1]: "Cache" is not really the correct verb: "debounce" is only slightly more accurate. Really, I want to avoid unnecessary changes when the value of dependency hasn't changed. Upstream may want the comparison predicate to be specifiable (common candidates are equal?, eqv?, and eq?, but custom predicates can be useful).
One possible performance concern may be dropping and re-creating large GUI (or framework—aka GUI Easy) objects with each state change. I think in particular the objects produced by
dyn-viewand similar conditional views may be redoing too much work when the (often derived) state they hasn't changed value but signals a change (often due to a change in a sibling branch of the state).Does GUI Easy already do some caching[^1] here? If not, is that something I can experiment with locally without forking (e.g., by creating my own
dyn-view&co. that do what I need)? [And if so, must this be at the OO layer or can it be done at the functional layer?]Or is something I must contribute upstream?
[^1]: "Cache" is not really the correct verb: "debounce" is only slightly more accurate. Really, I want to avoid unnecessary changes when the value of dependency hasn't changed. Upstream may want the comparison predicate to be specifiable (common candidates are equal?, eqv?, and eq?, but custom predicates can be useful).