feature request #6554
openThe 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
Updated by Andreas Müller about 7 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)
Updated by Patrick Plitzner almost 7 years ago
- Related to bug #6809: Name Editor throws double selection change events added
Updated by Patrick Plitzner over 6 years ago
- Related to feature request #7040: [MASTER] Improve UI performance added
Updated by Patrick Plitzner over 5 years 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()
Updated by Patrick Plitzner over 5 years 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
Updated by Patrick Plitzner over 5 years 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
Updated by Andreas Müller over 5 years 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?
Updated by Andreas Müller over 5 years ago
The count cache might be also something for the data portals
Updated by Patrick Plitzner over 5 years ago
- Related to feature request #7838: Optimize details view creation for section expansion added
Updated by Patrick Plitzner over 5 years ago
- Target version changed from Release 5.4 to Release 5.5
Updated by Patrick Plitzner about 5 years ago
- Target version changed from Release 5.5 to Release 5.6
Updated by Andreas Müller about 5 years ago
- Target version changed from Release 5.6 to Reviewed Next Major Release
Updated by Andreas Müller over 4 years ago
- Assignee changed from Patrick Plitzner to Katja Luther
Updated by Andreas Müller over 1 year ago
- Related to bug #10186: Problems with session handling in taxeditor added
Updated by Andreas Müller over 1 year ago
- Related to task #10187: Use only 1 service call to initialize supplemental data added
Updated by Katja Luther 3 months ago
Patrick Plitzner wrote in #note-4:
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()-> this is already solved by using db preference cache
Updated by Andreas Müller 2 months ago
- Target version changed from Reviewed Next Major Release to Release 5.45