EDIT

The main reason for the performance is the remote loading of each derivate (using its uuid) even after the entire list has already been loaded when search is clicked.

The reloading of the derivates on search should not be required since the derivate composite which contains the search button is part of the view implying that there will be no session conflict.

r26667 refactors the code to use a newly created service method to bulk load entities from a list of uuids, avoids reloading of the derivates for the search use-case and adds relevant property paths in the search manager.

Another main cause of performance issues is the

listTypeDesignations

call in the DerivateLabelProvider class.

This service method is invoked for each derivate in the view, which will be time consuming for long lists.

Since we already have the list of derivates before the first call to the label provider, it would be more performant to retrive all type designations in a single service call, cache the result and use it in the subsequent calls in the label provider.

Replying to p.plitzner:

Replying to c.mathew:

The type designations are only retrieved once for every derivative and cached afterwards so there should be no problem.

Retrieving the type designations (and determination events) for each derivate in the label provider is not scalable from a performance point of view. The performance is then tied to the number of derivates in the list since every derivate will require its own service call (two actually).

In addition to this, the caching mechanism for type designations (as is currently) does not work. Setting a breakpoint on the put call of the cache map reveals, that it is in fact never called. This is one of the reason why the updates in the details view fields which contribute to the derivate label are slow.

Another reason for the derivate view fields -> label update being slow is that any update of relevant fields in the details view updates the entire derivate view instead of just the single label in question. This should be ideally moved to a design where listeners are attached to the derivate entity which update specific tree nodes.

Replying to p.plitzner:

Replying to c.mathew:

Concerning the search performance: Searching with the search bar runs with an OK speed but when linked to taxon selection and a taxon with a lot of specimens is selected it still need a lot of time.

We should do the loading in an asynchronous job. Added this info to ticket #5402

I don't know if the performance can be increased even more. If not we can close this ticket.

The idea of a asynchronous job does make it more user friendly but does not solve the underlying remote loading performance issue. If there are specific use cases (like the one mentioned above), they should be checked to see which entities are loaded and these should be added to the property paths list as already done for this ticket.

In theory, with the right property paths setting the number of remote calls can be considerably reduced.