feature request #6554
The details views are newly created with every change of the focus
0%
Description
With every focus change the details view is created completely new. this leads to performance problems.
===
We should test if it is not possible to reuse certain precomputed details views or details view elements to improve performance
Related issues
Associated revisions
ref #6554 Avoid double destruction of details view sections
ref #6554 Avoid re-rendering of details view for same selection
ref #6554 Cache form section for taxon and derived unit details view
ref #6554 Fix class cast exception
ref #6554 Cache collection for entity collection sections
ref #6554 Avoid double setInput() on managedForm
ref #6554 set cached collection to null when entity is null
ref #6554 Implement update() for DeterminationDetailElement
ref #6554 Fix checkbox selection in update() method
ref #6554 Implement update() for taxon details view sections
ref #6554 Rename ISelectable interface to avoid ambiguity for checkboxes
ref #6554 Cache NameDetailElement (experimental)
ref #6554 Evaluate expansion state at widget creation time
ref #6554 Revert caching of NameDetailElement
ref #6554 Cache preferred terms in TermManager
ref #6554 Cache preferred terms in TermManager
ref #6554 Evaluate expansion state for remaining elements
ref #6554 Pull up isCached() to abstract data viewer class
ref #6554 Evaluate expansion state for missing sections
ref #6554 Avoid unnecessary refreshs
ref #6554 Fix initial expansion state
ref #6554 Set initial expansion state
History
#1 Updated by Andreas Müller almost 2 years ago
- Tracker changed from bug to feature request
- Subject changed from the details view are newly created with every change of the focus to The details views are newly created with every change of the focus
- Description updated (diff)
#2 Updated by Patrick Plitzner over 1 year ago
- Related to bug #6809: Name Editor throws double selection change events added
#3 Updated by Patrick Plitzner about 1 year ago
- Related to feature request #7040: [MASTER]Improve UI performance added
#4 Updated by Patrick Plitzner 4 months ago
The performance loss is separated in two areas:
- SWT/UI rendering
- can be optimized by caching the UI widgets
- cdm service layer calls
- can be optimized by reducing service calls
- We should also watch out for preference queries that contain service calls like e.g.
PreferencesUtil.getGlobalLanguage()
#5 Updated by Patrick Plitzner 4 months ago
- Status changed from New to In Progress
- Assignee changed from Katja Luther to Patrick Plitzner
- Target version changed from Unassigned CDM tickets to Release 5.4
#6 Updated by Patrick Plitzner 4 months ago
Another bottleneck is
org.hibernate.collection.internal.PersistentSet.size() org.hibernate.collection.internal.PersistentSet.iterator()
in some cases taking >90% of the rendering time of the supplemental data view
#7 Updated by Andreas Müller 4 months ago
Patrick Plitzner wrote:
Another bottleneck is
org.hibernate.collection.internal.PersistentSet.size() org.hibernate.collection.internal.PersistentSet.iterator()in some cases taking >90% of the rendering time of the supplemental data view
That is interesting. What exactly is it doing. Loading all data or only 1 request per Set to get the size?
I discussed this with Cherian already if we should have something like a count cache for persistend collections.
Or is it possible to combine the initialization or only the size-request for all supplemental data and not run it instance for instance?
#8 Updated by Andreas Müller 4 months ago
The count cache might be also something for the data portals
#9 Updated by Patrick Plitzner 3 months ago
- Related to feature request #7838: Optimize details view creation for section expansion added
#10 Updated by Patrick Plitzner 3 months ago
- Target version changed from Release 5.4 to Release 5.5
