EDIT

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()

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

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?

The count cache might be also something for the data portals

Patrick Plitzner wrote in #note-4:

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() -> this is already solved by using db preference cache