Każde wywołanie idzie przez jakiś wskaźnik - adres, nie ma różnicy.
call 0x6565776
czy takie coś:
call reg/mem
to żadna różnica.
Różnica jest przy nowoczesnych CPU. W kodzie typu call 0xABCD
nie trzeba nawet odpalać predykcji skoków, natomiast w kodzie typu call reg/mem
trzeba już to odpalić, a błędna predykcja to wyczyszczenie potoku, czyli kilkanaście/ kilkadziesiąt zmarnowanych cykli.
Do tego wywołania wirtualne to brak możliwości inlineowania, jak już wspomniał Krolik.
No i dlatego tam teraz ćwiczą te śmieszne skecze - niby optymalizacja, a faktyczne taka prowizoryczna próba naprawy kolosalnego buga.
Nie każdy ma ciśnienie na to, by ręcznie optymalizować kod, skoro JVMka sobie spokojnie radzi z niskopoziomowymi optymalizacjami. Zamiast zastanawiać się kiedy użyć metody wirtualnej, wskaźnika do metody, szablonu czy czego tam jeszcze albo np którego smart pointera użyć lub w jaki sposób alokować pamięć, Javowcy zastanawiają się jak zamodelować potrzeby biznesowe. I tak zresztą gdy projekt jest na tyle długowieczny, że programiści przy nim zmieniają się średnio co parę lat to w przypadku uber-mastah optymalizacji kolejni programiści nie wiedzieli by o co biegało poprzedniemu autorowi z jego fikuśnymi optymalizacjami.
Czas programisty jest cenny, a Java jest na tyle szybka, że klepanie aplikacji biznesowych w C++ zupełnie nie ma sensu. Zysk wydajnościowy z przepisania z Javy na C++ i tak byłby pomijalny przy większości aplikacji biznesowych, bo wąskim gardłem jest zwykle I/O (dysk lub sieć).
Między Javą, a C/ C++em jest jeszcze jedna różnica - w Javie wszystkie odwołania do tablic powodują sprawdzenie czy indeks nie wychodzi poza tablicę. Różnic jest dużo więcej, ale nawet z nimi wszystkimi JVM sobie w miarę dobrze radzi.
Swego czasu popełniłem kilka implementacji mojego autorskiego algorytmu kompresji: https://github.com/tarsa/TarsaLZP
Java vs C/ C++ (bez intrinsicsów) na enwik9:
189s vs 114s
PyPy to aż 1089s przy czym PyPy i tak jest generalnie eksperymentalne (tzn takie mam wrażenie, że nie jest wykorzystywane szeroko w produkcji).