|
| Description: |
*Steps to reproduce:*
# Watch a lot of 10k different pages (thousands?)
# Load a page.
*Expected result:*
The page loads fast.
*Actual result:*
Loading the page takes long, like 15 seconds. The flame graph in Glowroot suggest that a lot of time is spent loading the watch status:
!image-2025-05-28-14-30-38-913.png!
All of those traces end in one location - the constructor of {{ScopeNotificationFilterPreferencesHierarchy}}:
!image-2025-05-28-14-31-37-149.png!
Checking the [code|https://github.com/xwiki/xwiki-platform/blob/0497717cc64ab488520859e6fc70bbd2c50a0b9c/xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-filters/xwiki-platform-notifications-filters-api/src/main/java/org/xwiki/notifications/filters/internal/scope/ScopeNotificationFilterPreferencesHierarchy.java#L44-L60] shows that this is quadratic loop over scope notification preferences. The flame graph suggests that this is called several times per request, meaning that caching should bring quick benefits. Further, the [code of {{isParent}}|https://github.com/xwiki/xwiki-platform/blob/b30ff5fa89e3ebaf0df17cfc3013a7c3bda1632c/xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-filters/xwiki-platform-notifications-filters-api/src/main/java/org/xwiki/notifications/filters/internal/scope/ScopeNotificationFilterPreference.java#L115-L127] suggests that in addition to caching, there could be significant potential for optimizing this loop: only preferences that are exclusive can be parents, only preferences that are inclusive can be children. As it is very likely that a user won't have thousands of preferences of both types, a simple optimization should be to first filter the preferences by type and then only to compute parent-child relationships between those of different type. |
|
