O(logN) complexity needed instead of O(N logN) when picking up multiple matching campaigns N>1
venediktov opened this issue · comments
Vladimir Venediktov commented
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 commented
Hey, I am interested in resolving this issue