...

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

...

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
  • 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 consumes about 200 MByte when scrolling in it - this memory stays after GC and is only freed when switching to another view