Chrome has quite a few hot places, where the same virtual is called inside a loop (sometimes, double loop). Initially, that was discovered during the analysis of the performance regressions due to enabling CFI ( https://crbug.com/634139#c12 , but the (somewhat lower) overhead being paid by the regular build as well.

From V8:
https://cs.chromium.org/chromium/src/v8/src/global-handles.cc?sq=package:chromium&rcl=1470309818&l=1158

void GlobalHandles::IterateAllRootsWithClassIds(ObjectVisitor* v) {
  for (NodeIterator it(this); !it.done(); it.Advance()) {
    if (it.node()->IsRetainer() && it.node()->has_wrapper_class_id()) {
      v->VisitEmbedderReference(it.node()->location(),
                                it.node()->wrapper_class_id());
    }
  }
}

From CC:
https://cs.chromium.org/chromium/src/cc/playback/display_item_list.cc?q=DisplayItemList::Raster&sq=package:chromium&dr=CSs&l=132

void DisplayItemList::Raster(SkCanvas* canvas,
                             SkPicture::AbortCallback* callback) const {
...
  for (size_t index : indices) {
    ...
    if (callback && callback->abort())
      break;
  }
}

In both cases a pointer to the particular implementation can be computed before a loop, as nor the type of the visitor, nor the type of the callback are being changed there. So, instead of a virtual call, where we read vptr, then read from vtable by the index, then jump, we can same the pointer and then make an indirect jump without additional loads or instructions.

We need to double check with C++ standard experts that such optimization is allowed.