Rasaiya,

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.

Hi Rasiya

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.

You should avoid isinpagelist; that is an iteration over the structure and you will see an average of size/2 loops over the structure, assuming even distribution of 'hot data'.

The page group will be a direct index on the key, so should perform better.

You may also wish to consider using property references in list B if there is a flag in the objects you can reference to just test to skip, instead of looking in A.

>>> 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

                 .myPageGroup("royal blue").popularity

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.

/Eric

Seems that page group is better than Page list as it uses mapvalue.

So it should be faster.