Problem Code/Change/GetChangesMacro ends with:
#set ($changeItems = $query.execute())
with no setLimit/setOffset. Every ChangeDisplayer* page then loads each row as a full document inside the loop:
#foreach ($item in $changeItems)
#set ($changeDoc = $xwiki.getDocument($item))
So one call is one unbounded query plus one document load per result. Consequence The result-set size is driven by user input: Code/Report forwards the report form's fields straight into getChanges, and the macro's own defaults are versions=% and categories=%. A report submitted with only a product runs one query returning every change of that product ever recorded, then issues one document load per row — thousands on a wiki with years of release notes, in a single request. The Grid displayer additionally resolves attachments per card. A release note page is also heavier than it looks: Code/Change/ReleaseNotesChangesMacro calls getChanges six times (two per audience section). Notes Query#setLimit is already used elsewhere in this application (Code/EntryVelocityMacros), so the fix is local: bound the query, and either page the display or select the needed properties in the query instead of re-loading each document. See the XWiki performance conventions on preferring pagination over loading an entire unbounded result set. |
