Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0051291 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
feature request | [Retail Modules] Web POS | major | have not tried | 2023-01-05 13:02 | 2023-01-05 13:02 | |||||||
Reporter | AugustoMauch | View Status | public | |||||||||
Assigned To | Triage Platform Base | |||||||||||
Priority | normal | Resolution | open | Fixed in Version | ||||||||
Status | new | Fix in branch | Fixed in SCM revision | |||||||||
Projection | none | ETA | none | Target Version | ||||||||
OS | Any | Database | Any | Java version | ||||||||
OS Version | Database version | Ant version | ||||||||||
Product Version | SCM revision | |||||||||||
Review Assigned To | ||||||||||||
Regression level | ||||||||||||
Regression date | ||||||||||||
Regression introduced in release | ||||||||||||
Regression introduced by commit | ||||||||||||
Triggers an Emergency Pack | No | |||||||||||
Summary | 0051291: Improving the granularity of PersistenceChangeListenerManager will have a positive performance impact | |||||||||||
Description | We use the PersistenceChangeListenerManager to react to certain changes in the application state. For instance, configurations of ConfigurationSets use it to reevaluate the configurations when a given state model is updated, and UserActions do something similar to reevaluate the executability rules when relevant models are updated. Right now PersistenceChangeListenerManager allows to subscribe to whole models (Ticket, UI, etc). This can be problematic because most of the times someone gets subscribed to that listener, it is only interested on a slice of the model (for instance many executability rules listen to changes in any UI property when the only relevant one for them is UI.currentWindow). Improving the granularity of the slice of the state being listened to will have a positive performance impact because fewer executability rules and configurations will be reevaluated when a UI state action is executed (and we are executing those VERY often). The price to pay will be to compare the value of the listened state slices before and after each action is executed. We should compare the new cost with the saved cost, but it is probably worth it. Proposed API: - Maintain listening to the whole model when needed: addListenedModels(['Ticket']) - Add a new more granular listener: addListenedModelProperty(['UI.currentWindow']) | |||||||||||
Steps To Reproduce | - | |||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | ||||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
Issue History | |||
Date Modified | Username | Field | Change |
2023-01-05 13:02 | AugustoMauch | New Issue | |
2023-01-05 13:02 | AugustoMauch | Assigned To | => Triage Platform Base |
2023-01-05 13:02 | AugustoMauch | Triggers an Emergency Pack | => No |
Copyright © 2000 - 2009 MantisBT Group |