Consider doing bulk processing in SV scan iterator

[siddharthteotia]

`
public int next() {
  while (_nextDocId < _numDocs) {
    int nextDocId = _nextDocId++;
    _numEntriesScanned++;
    if (_valueMatcher.doesValueMatch(nextDocId)) {
      return nextDocId;
    }
  }
  return Constants.EOF;
}
`

https://github.com/apache/pinot/blob/master/pinot-core/src/main/java/org/apache/pinot/core/operator/dociditerators/SVScanDocIdIterator.java

Bulk API can potentially be added to do this in a tight-loop (vectorized like manner) for few fixed number of records at a time as opposed to a function call to doesValueMatch per document. May be there is way to change interface such that caller of iterator can possibly directly doesValueMatch in a tight-loop

[siddharthteotia]

• It seems like there is a potential performance overhead associated with dynamic virtual call dispatch given that "vtable stub" shows up as taking top 22% of time.
• This is most likely coming from return _reader.read(docId) in FixedBitSVForwardIndexReaderV2 as the read() call has to be dispatched to the actual bit reader (1 of 32 types)
• The function call overhead and in fact virtual dispatch overhead can probably be optimized if we convert the APIs to bulk based in SVScanDocIdIterator -- next() gathers docIds in an array (will have to figure out the batch sizing etc) -- calls doesValueMatch on array instead of a single docId -- Call FixedBitSVForwardIndexReaderV2.readDictIds() instead of FixedBitSVForwardIndexReaderV2.getDictId as done in today's code -- Call _predicateEvaluator.applySV on an array / batch of dictIds

80% of the time is spent in doesValueMatch().

• 60% in FixedBitSVForwardIndexReaderV2.getdictId
• 10% each in accessing the outer class member variable (I am not super sure if this is even possible but can investigate)

[siddharthteotia]

@vvivekiyer is going to take a stab at this.