O(logN) complexity needed instead of O(N logN) when picking up multiple matching campaigns N>1

[venediktov]

Looks like last stage when we pick up campaigns from the cache the complexity is O(N LogN) , for every matched campaign id N we use LogN complexity lookup in the last cached table ~ O(N LogN) . Matching 20-30 campaign per request is within our benchmark goals however going above this number degrades performance.

• Use relational cache entries to solve the issue , we should avoid last stage campaign lookup , rather have pointers saved in the preceding matcher cache and use those pointers to retrieve campaigns directly instead of performing O(LogN) lookup.

[AKAnkshASing]

Hey, I am interested in resolving this issue