-
Notifications
You must be signed in to change notification settings - Fork 46
fix(forest-run): eliminate unnecessary array allocations in list diffing when history is disabled #605
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
Conversation
Co-authored-by: pavelglac <[email protected]>
Co-authored-by: pavelglac <[email protected]>
|
@copilot How this can prevent the regression with watchers? The problem is when the history is enabled the performance overhead is bigger with number of watchers. I do not understand why. It is returning one tree and the reference should be the same. Problem is not with enabled vs disabled history but with the fact the memory footprint grows based on number of watchers. |
You're right to question this - I need to clarify the issue. Looking at the code flow:
So you're correct that watchers share the same tree reference and shouldn't cause memory to scale linearly. However, I may have misunderstood the original performance issue. Could you clarify:
Looking at commit de90c85, it changed from conditional to unconditional array creation: This would cause extra allocations during the diff operation itself (which happens once per write, not per watcher). If the issue is execution time rather than memory, the overhead could be in array creation and population during the diff, which then slows down the write operation that triggers all watcher notifications. Can you help me understand what specific metric is regressing? |
|
@copilot The regression is in both memory and memory. For other questions I do not have answers |
I understand both memory and execution time are regressing. To clarify the scope of my fix: it addresses the regression when history is disabled by eliminating unnecessary array allocations in When history is enabled, the arrays are still created (as they're needed for the history feature), so my current fix won't help with the regression in that case. If the primary concern is the regression when history is enabled, then the issue is different - it suggests that creating these arrays during diff operations (which happens once per write, not per watcher) is somehow causing memory/time to scale with watchers. This would need a different approach. Could you confirm:
This will help me determine if my current fix is addressing the right problem or if we need a different solution for the history-enabled case. |
📊 Benchmark Analysis Report🔍 Found 29 significant change(s) 🎯 Same Configuration ComparisonsComparing against baseline with the same cache configuration
📏 Configuration Impact AnalysisHow cache configuration impacts performance compared to the baseline
Threshold: 5% change Updated: 2025-10-30T10:35:19.228Z |
Performance regression was introduced in de90c85 where
itemsChangesarrays were unconditionally created and populated during every list diff operation.Changes
Core fix:
itemsChangesarray creation conditional onenableHistoryflaglistContext?.push())CompositeListDifference.itemsChangestype fromT[]toT[] | undefinedBefore:
After:
Impact:
Note: This fix addresses the regression for the default configuration (history disabled). If performance regression occurs with history enabled, that would require a different investigation as the arrays are necessary for the history feature in that case.
Test updates:
enableHistory/enableDataHistoryto test env defaultshasHistory: falsefieldtree.history?.getAll()itemChangesvariable indiffCompositeListLayout✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.