Status Quo

Running performance tests against M5 (beta2) we got the impression that M5 is consuming quite a lot of memory per user. That's why we wanted to optimize.

Analysed Components 

ContentApps + containers

tree

• is not using paging - reads all child nodes when expanding

• inherits AbstractJcrContainerupdateSize() -> required to write no of items footer - that's pretty expensive!

list

• queries for all elements to get total size - then queries the content using a paging mechanism

thumbnail

• doesn't extend AbstractJcrContainer, doesn't use its paging mechanism
• has its own lazy loading mechanism: loads when required but then keeps all read items (images) until we switch to another view

Setup

For the analysis we used the contacts app. There we added 10'000 contacts all having a random street (2000 chars), city (100 chars) + organization name (20'000 chars) as well as one identical image (11kbyte). See attached script for further details.

Results

• starting contacts app consumes 20-30 MByte of additional memory - to be analyzed what's happing there
• could not measure a diff between querying "select *..." of "select [jcr:uuid]..." in AbstractJcrContainer#updateSize()
• list view temporarily consumes about 100 MByte but this goes aways on GC - this is true even when scrolling around
• thumbnail view easily consumes about 200 MByte when scrolling in it - system gets pretty slow
• JcrItemAdapters are quite transient - they're used when populating content views but once data is read, we only reference few instances