Community
Participate
Working Groups
It seems that calls to IPreferencesService methods can be time consumming. Then we must avoid call it in TreeItem expansion, especially when a huge hierarchy is expand with "*" shortcut on Windows. Then to avoid that, autoRefresh preference value must be get once at DTreeViewerListener initialisation in a class field and a listener must be written to update this field on preference change. Currently IPreferencesService is used but has not method to add a listener. There is IPreferenceChangeListener but only applicable on IPreferenceStore of JFace which is then UI dependant. There is also IEclipsePreferences on which we can have INodeChangeListener. Then this bugzilla is to analyse what to do.
I would change the scope of this issue to use a preference listener instead of systematically ask to the preference service everywhere it makes sence. At least, auto-refresh value should be kept in a central cache and updated through a preference listener. Marking issue as triaged as this is a valid feature request.
This is exactly in the scope of bug 442862, which was opened for the same issue in GroupingContentProvider, but in which we planned to look for other culprits in the code. https://git.eclipse.org/r/#/c/32529/ proposes a solution for GroupinContentProvider which tries to be a little more general. I'm not sure if in its current state it can be reused for tree item expansion, but if it can't, it should be modified.
I've renamed this ticket to keep its scope on the tree item expansion part. I'll probably open a new one for the GroupingContentProvider case, so that bug 442862 can be kept for the general problem, and each individual case has its own ticket.
Note that this issue does not happen in the current master branch, but is a side-effect/followup of https://git.eclipse.org/r/#/c/22444/, a proposed change for bug 428756. Basically, if/when that change is merged, then this issue with preference accesses will probably need to be adressed to get more of the performance benefits.
