You raise an interesting question. I suggest that you just construct two test cases that implement your 2 scenarios, pump in a lot of data, and then measure the performance of each. Tracer will probably give you a good enough report on the performance. I assume you will be working in Production with lots and lots of data, and/or executing very frequently? Otherwise, you don't really care which way you implement things.
I would prefer to use page group. This will override the duplicate data. It means you are removing the duplicate records. Say: page list has Name: sam in Page 1,4 and 5 if you iterate this on page group all the duplicate records with Sam can be removed. This is based on subscript.
>>> The page group will be a direct index on the key, so should perform better
I'm curious about this. Certainly from the Pega developer viewpoint, it looks like a direct index, for instance
The developer regards that "royal blue" index as a direct index, but suppose myPageGroup has thousands of entries in it. Under the hood, how is the "royal blue" index found. I'm curious whether perhaps under the hood there's just a similar iterative loop that scans until an entry with index "royal blue" is found, similar to what a developer would do when using a page list instead and needing to scan for an entry containing a particular value for a property.
Page List and Page Group map to List and Map interfaces in Java. I guess Page Group might have been implemented using Map interface. If it is the case then lookup of an object in Page Group will be faster as it uses hashing logic which requires looking up objects in related bucket rather than scanning all objects iteratively.