Project

General

Profile

Actions
Copy link

feature request #6554

open

The details views are newly created with every change of the focus

Added by Katja Luther over 5 years ago. Updated about 3 years ago.

Status:
In Progress
Priority:
Highest
Assignee:
Katja Luther
Category:
taxeditor
Target version:
Reviewed Next Major Release
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
normal

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

Related to EDIT - bug #6809: Name Editor throws double selection change eventsClosedPatrick Plitzner

Actions
Related to EDIT - feature request #7040: [MASTER] Improve UI performanceNewKatja Luther

Actions
Related to EDIT - feature request #7838: Optimize details view creation for section expansionClosedPatrick Plitzner

Actions
Actions
Copy link
 #1

Updated by Andreas Müller over 5 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)
Actions
Copy link
 #2

Updated by Patrick Plitzner over 5 years ago

  • Related to bug #6809: Name Editor throws double selection change events added
Actions
Copy link
 #3

Updated by Patrick Plitzner about 5 years ago

Actions
Copy link
 #4

Updated by Patrick Plitzner about 4 years ago

The performance loss is separated in two areas:

  1. SWT/UI rendering
    • can be optimized by caching the UI widgets
  2. 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()
Actions
Copy link
 #5

Updated by Patrick Plitzner about 4 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
Actions
Copy link
 #6

Updated by Patrick Plitzner about 4 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

Actions
Copy link
 #7

Updated by Andreas Müller about 4 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?

Actions
Copy link
 #8

Updated by Andreas Müller about 4 years ago

The count cache might be also something for the data portals

Actions
Copy link
 #9

Updated by Patrick Plitzner about 4 years ago

Actions
Copy link
 #10

Updated by Patrick Plitzner about 4 years ago

  • Target version changed from Release 5.4 to Release 5.5
Actions
Copy link
 #11

Updated by Patrick Plitzner almost 4 years ago

  • Target version changed from Release 5.5 to Release 5.6
Actions
Copy link
 #12

Updated by Andreas Müller almost 4 years ago

  • Target version changed from Release 5.6 to Reviewed Next Major Release
Actions
Copy link
 #13

Updated by Andreas Müller about 3 years ago

  • Assignee changed from Patrick Plitzner to Katja Luther
Actions
Copy link

Also available in: Atom PDF