Pracuję nad aplikacją, a jedno podejście projektowe wymaga bardzo intensywnego użycia instanceofoperatora. Chociaż wiem, że projektowanie OO ogólnie stara się unikać używania instanceof, to inna historia i to pytanie jest wyłącznie związane z wydajnością. Zastanawiałem się, czy ma to wpływ na wydajność? Czy to jest tak szybkie jak ==?

Na przykład mam klasę podstawową z 10 podklasami. W jednej funkcji, która pobiera klasę podstawową, sprawdzam, czy klasa jest instancją podklasy i wykonuję jakąś procedurę.

Jednym z innych sposobów, w jaki myślałem o jego rozwiązaniu, było użycie prymitywu liczb całkowitych typu „id” zamiast tego i użycie maski bitowej do reprezentowania kategorii podklas, a następnie po prostu porównanie maski podklasy „identyfikator typu” z stała maska ​​reprezentująca kategorię.

Czy instanceofJVM jest w jakiś sposób zoptymalizowany, aby był szybszy? Chcę trzymać się Javy, ale wydajność aplikacji ma kluczowe znaczenie. Byłoby fajnie, gdyby ktoś, kto był na tej drodze wcześniej, mógł udzielić porady. Czy za dużo robię, czy koncentruję się na niewłaściwej optymalizacji?

Nowoczesne kompilatory JVM / JIC usunęły wydajność większości tradycyjnych „powolnych” operacji, w tym instancji, obsługi wyjątków, odbicia itp.

Jak napisał Donald Knuth: „Powinniśmy zapomnieć o małej wydajności, powiedzmy w około 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła”. Wydajność instanceof prawdopodobnie nie będzie problemem, więc nie marnuj czasu na wymyślanie egzotycznych obejść, dopóki nie masz pewności, że to jest problem.

Podejście

Napisałem program porównawczy do oceny różnych wdrożeń:

1. instanceof wdrożenie (jako odniesienie)
2. obiekt zorientowany za pomocą klasy abstrakcyjnej i @Overridemetody testowej
3. za pomocą implementacji własnego typu
4. getClass() == _.class realizacja

Użyłem jmh do uruchomienia testu porównawczego ze 100 wywołaniami rozgrzewki, 1000 iteracji pod pomiarem i 10 widelcami. Tak więc każda opcja była mierzona 10 000 razy, co zajmuje 12:18:57, aby uruchomić cały test porównawczy na moim MacBooku Pro z macOS 10.12.4 i Javą 1.8. Benchmark mierzy średni czas każdej opcji. Aby uzyskać więcej informacji, zobacz moją implementację na GitHub .

Ze względu na kompletność: istnieje poprzednia wersja tej odpowiedzi i mój test porównawczy .

Wyniki

| Operacja | Czas działania w nanosekundach na operację | W odniesieniu do instanceof |
| ------------ | ------------------------------------ - | ------------------------ |
| INSTANCEOF | 39 598 ± 0,022 ns / op | 100,00% |
| GETCLASS | 39 687 ± 0,021 ns / op | 100,22% |
| TYP | 46,295 ± 0,026 ns / op | 116,91% |
| OO | 48,078 ± 0,026 ns / op | 121,42% |

tl; dr

W Javie 1.8 instanceofjest najszybszym podejściem, choć getClass()jest bardzo blisko.

Właśnie wykonałem prosty test, aby zobaczyć, jak wydajność instanceOf wypada w porównaniu z prostym wywołaniem s.equals () do obiektu łańcuchowego zawierającego tylko jedną literę.

w pętli 10.000.000 instancjaOf dała mi 63-96ms, a ciąg równości dał mi 106-230ms

Użyłem java jvm 6.

Tak więc w moim prostym teście jest szybsze wykonanie instanceOf zamiast porównania ciągu znaków.

użycie Integer .equals () zamiast łańcucha dało mi ten sam wynik, tylko gdy użyłem == i byłem szybszy niż instanceOf o 20ms (w pętli 10.000.000)

Elementy, które określą wpływ na wydajność, to:

1. Liczba możliwych klas, dla których operator instanceof może zwrócić wartość true
2. Dystrybucja twoich danych - czy większość instancji operacji jest rozwiązana w pierwszej czy drugiej próbie? Będziesz chciał postawić swoje najprawdopodobniej na pierwszym miejscu prawdziwe operacje.
3. Środowisko wdrażania. Uruchamianie na maszynie wirtualnej Sun Solaris różni się znacznie od maszyny JVM firmy Windows. Solaris będzie domyślnie działał w trybie „serwera”, podczas gdy system Windows będzie działał w trybie klienta. Dzięki optymalizacji JIT w systemie Solaris dostęp do wszystkich metod będzie taki sam.

Stworzyłem znak mikrodruku dla czterech różnych metod wysyłki . Wyniki z Solaris są następujące, przy czym mniejsza liczba jest szybsza:

InstanceOf 3156
class== 2925 
OO 3083 
Id 3067 

Odpowiadając na twoje ostatnie pytanie: Chyba że profiler powie Ci, że spędzasz absurdalnie dużo czasu w instancji: Tak, jesteś podstępny.

Zanim zaczniesz zastanawiać się nad optymalizacją czegoś, co nigdy nie wymagało optymalizacji: napisz swój algorytm w najbardziej czytelny sposób i uruchom go. Uruchom go, aż kompilator jit dostanie szansę na jego optymalizację. Jeśli masz problemy z tym fragmentem kodu, skorzystaj z narzędzia do profilowania, aby dowiedzieć się, gdzie uzyskać najwięcej i zoptymalizować to.

W czasach wysoce optymalizujących kompilatorów twoje przypuszczenia dotyczące wąskich gardeł prawdopodobnie będą całkowicie błędne.

I w prawdziwym duchu tej odpowiedzi (w którą wierzę całym sercem): Absolutnie nie wiem, jak instancje i == odnoszą się, kiedy kompilator jit ma szansę go zoptymalizować.

Zapomniałem: Nigdy nie mierz pierwszego uruchomienia.

Mam to samo pytanie, ale ponieważ nie znalazłem „wskaźników wydajności” dla przypadku użycia podobnego do mojego, zrobiłem trochę więcej przykładowego kodu. Na moim sprzęcie i Javie 6 i 7 różnica między wystąpieniem instancji i włączeniem iteracji 10mln jest następująca

for 10 child classes - instanceof: 1200ms vs switch: 470ms
for 5 child classes  - instanceof:  375ms vs switch: 204ms

Tak więc instanceof jest naprawdę wolniejszy, szczególnie w przypadku dużej liczby instrukcji if-else-if, jednak różnica będzie znikoma w rzeczywistej aplikacji.

import java.util.Date;

public class InstanceOfVsEnum {

    public static int c1, c2, c3, c4, c5, c6, c7, c8, c9, cA;

    public static class Handler {
        public enum Type { Type1, Type2, Type3, Type4, Type5, Type6, Type7, Type8, Type9, TypeA }
        protected Handler(Type type) { this.type = type; }
        public final Type type;

        public static void addHandlerInstanceOf(Handler h) {
            if( h instanceof H1) { c1++; }
            else if( h instanceof H2) { c2++; }
            else if( h instanceof H3) { c3++; }
            else if( h instanceof H4) { c4++; }
            else if( h instanceof H5) { c5++; }
            else if( h instanceof H6) { c6++; }
            else if( h instanceof H7) { c7++; }
            else if( h instanceof H8) { c8++; }
            else if( h instanceof H9) { c9++; }
            else if( h instanceof HA) { cA++; }
        }

        public static void addHandlerSwitch(Handler h) {
            switch( h.type ) {
                case Type1: c1++; break;
                case Type2: c2++; break;
                case Type3: c3++; break;
                case Type4: c4++; break;
                case Type5: c5++; break;
                case Type6: c6++; break;
                case Type7: c7++; break;
                case Type8: c8++; break;
                case Type9: c9++; break;
                case TypeA: cA++; break;
            }
        }
    }

    public static class H1 extends Handler { public H1() { super(Type.Type1); } }
    public static class H2 extends Handler { public H2() { super(Type.Type2); } }
    public static class H3 extends Handler { public H3() { super(Type.Type3); } }
    public static class H4 extends Handler { public H4() { super(Type.Type4); } }
    public static class H5 extends Handler { public H5() { super(Type.Type5); } }
    public static class H6 extends Handler { public H6() { super(Type.Type6); } }
    public static class H7 extends Handler { public H7() { super(Type.Type7); } }
    public static class H8 extends Handler { public H8() { super(Type.Type8); } }
    public static class H9 extends Handler { public H9() { super(Type.Type9); } }
    public static class HA extends Handler { public HA() { super(Type.TypeA); } }

    final static int cCycles = 10000000;

    public static void main(String[] args) {
        H1 h1 = new H1();
        H2 h2 = new H2();
        H3 h3 = new H3();
        H4 h4 = new H4();
        H5 h5 = new H5();
        H6 h6 = new H6();
        H7 h7 = new H7();
        H8 h8 = new H8();
        H9 h9 = new H9();
        HA hA = new HA();

        Date dtStart = new Date();
        for( int i = 0; i < cCycles; i++ ) {
            Handler.addHandlerInstanceOf(h1);
            Handler.addHandlerInstanceOf(h2);
            Handler.addHandlerInstanceOf(h3);
            Handler.addHandlerInstanceOf(h4);
            Handler.addHandlerInstanceOf(h5);
            Handler.addHandlerInstanceOf(h6);
            Handler.addHandlerInstanceOf(h7);
            Handler.addHandlerInstanceOf(h8);
            Handler.addHandlerInstanceOf(h9);
            Handler.addHandlerInstanceOf(hA);
        }
        System.out.println("Instance of - " + (new Date().getTime() - dtStart.getTime()));

        dtStart = new Date();
        for( int i = 0; i < cCycles; i++ ) {
            Handler.addHandlerSwitch(h1);
            Handler.addHandlerSwitch(h2);
            Handler.addHandlerSwitch(h3);
            Handler.addHandlerSwitch(h4);
            Handler.addHandlerSwitch(h5);
            Handler.addHandlerSwitch(h6);
            Handler.addHandlerSwitch(h7);
            Handler.addHandlerSwitch(h8);
            Handler.addHandlerSwitch(h9);
            Handler.addHandlerSwitch(hA);
        }
        System.out.println("Switch of - " + (new Date().getTime() - dtStart.getTime()));
    }
}

instanceof jest naprawdę szybki, biorąc tylko kilka instrukcji procesora.

Najwyraźniej, jeśli klasa Xnie ma załadowanych żadnych podklas (JVM wie), instanceofmożna zoptymalizować jako:

     x instanceof X    
==>  x.getClass()==X.class  
==>  x.classID == constant_X_ID

Główny koszt to tylko odczyt!

Jeśli Xma załadowane podklasy, potrzeba jeszcze kilku odczytów; prawdopodobnie są w tej samej lokalizacji, więc dodatkowy koszt jest również bardzo niski.

Dobre wieści wszyscy!

Instancjaof jest bardzo szybka. Sprowadza się do kodu bajtowego, który jest używany do porównania referencji klas. Wypróbuj kilka milionów instancji w pętli i przekonaj się sam.

instanceof będzie prawdopodobnie bardziej kosztowny niż zwykły równy w większości rzeczywistych implementacji (to znaczy tych, w których instanceof jest naprawdę potrzebny, i nie można go po prostu rozwiązać, zastępując wspólną metodę, jak każdy podręcznik dla początkujących, a także Demian powyżej sugeruje).

Dlaczego? Ponieważ prawdopodobnie stanie się tak, że masz kilka interfejsów, które zapewniają pewną funkcjonalność (powiedzmy, interfejsy x, yiz) oraz niektóre obiekty do manipulowania, które mogą (lub nie) implementować jeden z tych interfejsów ... ale nie bezpośrednio. Powiedzmy na przykład, że mam:

w rozszerza x

A implementuje w

B rozciąga się na A

C rozszerza B, implementuje y

D rozszerza C, implementuje z

Załóżmy, że przetwarzam instancję D, obiekt d. Obliczenia (d instanceof x) wymagają pobrania d.getClass (), przejścia przez interfejsy, które implementuje, aby dowiedzieć się, czy jeden jest == do x, a jeśli nie, wykonaj to rekurencyjnie dla wszystkich ich przodków ... W naszym przypadku jeśli przeprowadzisz pierwszą eksplorację tego drzewa, uzyskasz co najmniej 8 porównań, zakładając, że y i z niczego nie przedłużają ...

Złożoność drzewa pochodnego w świecie rzeczywistym prawdopodobnie będzie wyższa. W niektórych przypadkach JIT może zoptymalizować większość z nich, jeśli jest w stanie rozwiązać z góry d jako we wszystkich możliwych przypadkach, instancję czegoś, co rozszerza x. Jednak realistycznie przez większość czasu będziesz przechodził przez to drzewo.

Jeśli stanie się to problemem, sugerowałbym zamiast tego użyć mapy modułu obsługi, łącząc konkretną klasę obiektu z zamknięciem, które obsługuje. Usuwa fazę przejścia drzewa na korzyść bezpośredniego mapowania. Uważaj jednak, że jeśli ustawiłeś moduł obsługi dla C.class, mój obiekt d powyżej nie zostanie rozpoznany.

oto moje 2 centy, mam nadzieję, że pomogą ...

instanceof jest bardzo wydajny, więc raczej nie ucierpi Twoja wydajność. Jednak użycie wielu instancji sugeruje problem projektowy.

Jeśli możesz użyć xClass == String.class, jest to szybsze. Uwaga: nie potrzebujesz instanceof do końcowych zajęć.

Zasadniczo powodem, dla którego operator „instanceof” jest niezadowolony w takim przypadku (gdy instanceof sprawdza podklasy tej klasy bazowej), jest to, że powinieneś zrobić, aby przenieść operacje do metody i zastąpić ją dla odpowiedniego podklasy. Na przykład, jeśli masz:

if (o instanceof Class1)
   doThis();
else if (o instanceof Class2)
   doThat();
//...

Możesz to zastąpić

o.doEverything();

a następnie mieć implementację „doEverything ()” w wywołaniu klasy 1 „doThis ()”, a w wywołaniu klasy 2 „doThat ()” i tak dalej.

„instanceof” jest w rzeczywistości operatorem, takim jak + lub - i uważam, że ma własną instrukcję kodu bajtowego JVM. Powinno być dość szybko.

Nie powinienem twierdzić, że jeśli masz przełącznik, w którym testujesz, czy obiekt jest instancją jakiejś podklasy, wtedy twój projekt może wymagać przeróbki. Rozważ przesunięcie zachowania specyficznego dla podklasy do samych podklas.

Demian i Paul wspominają o dobrym punkcie; jednak umieszczenie kodu do wykonania naprawdę zależy od tego, jak chcesz użyć danych ...

Jestem wielkim fanem małych obiektów danych, których można używać na wiele sposobów. Jeśli zastosujesz metodę nadpisywania (polimorficzną), twoich obiektów można używać tylko „w jedną stronę”.

To tutaj pojawiają się wzory ...

Możesz użyć podwójnej wysyłki (jak we wzorcu gościa), aby poprosić każdy obiekt, aby „zadzwonił do ciebie”, przechodząc sam - to rozwiąże rodzaj obiektu. jednak (ponownie) będziesz potrzebować klasy, która może „robić rzeczy” ze wszystkimi możliwymi podtypami.

Wolę używać wzorca strategii, w którym możesz zarejestrować strategie dla każdego podtypu, który chcesz obsłużyć. Coś takiego jak poniżej. Pamiętaj, że pomaga to tylko w dopasowaniu dokładnych typów, ale ma tę zaletę, że można je rozszerzać - osoby trzecie mogą dodawać własne typy i moduły obsługi. (Jest to dobre w przypadku dynamicznych platform, takich jak OSGi, do których można dodawać nowe pakiety)

Mam nadzieję, że zainspiruje to inne pomysły ...

package com.javadude.sample;

import java.util.HashMap;
import java.util.Map;

public class StrategyExample {
    static class SomeCommonSuperType {}
    static class SubType1 extends SomeCommonSuperType {}
    static class SubType2 extends SomeCommonSuperType {}
    static class SubType3 extends SomeCommonSuperType {}

    static interface Handler<T extends SomeCommonSuperType> {
        Object handle(T object);
    }

    static class HandlerMap {
        private Map<Class<? extends SomeCommonSuperType>, Handler<? extends SomeCommonSuperType>> handlers_ =
            new HashMap<Class<? extends SomeCommonSuperType>, Handler<? extends SomeCommonSuperType>>();
        public <T extends SomeCommonSuperType> void add(Class<T> c, Handler<T> handler) {
            handlers_.put(c, handler);
        }
        @SuppressWarnings("unchecked")
        public <T extends SomeCommonSuperType> Object handle(T o) {
            return ((Handler<T>) handlers_.get(o.getClass())).handle(o);
        }
    }

    public static void main(String[] args) {
        HandlerMap handlerMap = new HandlerMap();

        handlerMap.add(SubType1.class, new Handler<SubType1>() {
            @Override public Object handle(SubType1 object) {
                System.out.println("Handling SubType1");
                return null;
            } });
        handlerMap.add(SubType2.class, new Handler<SubType2>() {
            @Override public Object handle(SubType2 object) {
                System.out.println("Handling SubType2");
                return null;
            } });
        handlerMap.add(SubType3.class, new Handler<SubType3>() {
            @Override public Object handle(SubType3 object) {
                System.out.println("Handling SubType3");
                return null;
            } });

        SubType1 subType1 = new SubType1();
        handlerMap.handle(subType1);
        SubType2 subType2 = new SubType2();
        handlerMap.handle(subType2);
        SubType3 subType3 = new SubType3();
        handlerMap.handle(subType3);
    }
}

Piszę test wydajności oparty na jmh-java-benchmark-archetype: 2.21. JDK to openjdk, a wersja to 1.8.0_212. Maszyna testowa to Mac Pro. Wynik testu to:

Benchmark                Mode  Cnt    Score   Error   Units
MyBenchmark.getClasses  thrpt   30  510.818 ± 4.190  ops/us
MyBenchmark.instanceOf  thrpt   30  503.826 ± 5.546  ops/us

Wynik pokazuje, że: getClass jest lepszy niż instanceOf, co jest sprzeczne z innym testem. Nie wiem jednak dlaczego.

Kod testowy znajduje się poniżej:

public class MyBenchmark {

public static final Object a = new LinkedHashMap<String, String>();

@Benchmark
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public boolean instanceOf() {
    return a instanceof Map;
}

@Benchmark
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public boolean getClasses() {
    return a.getClass() == HashMap.class;
}

public static void main(String[] args) throws RunnerException {
    Options opt =
        new OptionsBuilder().include(MyBenchmark.class.getSimpleName()).warmupIterations(20).measurementIterations(30).forks(1).build();
    new Runner(opt).run();
}
}

Trudno powiedzieć, w jaki sposób określona JVM implementuje instancję, ale w większości przypadków Obiekty są porównywalne do struktur, a klasy też, a każda struktura obiektu ma wskaźnik do struktury klasy, której jest instancją. Tak więc instancja dla

if (o instanceof java.lang.String)

może być tak szybki jak następujący kod C.

if (objectStruct->iAmInstanceOf == &java_lang_String_class)

zakładając, że kompilator JIT jest na miejscu i wykonuje dobrą robotę.

Biorąc pod uwagę, że jest to tylko dostęp do wskaźnika, uzyskanie wskaźnika przy pewnym przesunięciu, do którego wskazuje wskaźnik, i porównanie go z innym wskaźnikiem (co jest w zasadzie tym samym, co testowanie przy równych liczbach 32-bitowych), powiedziałbym, że operacja może faktycznie bądź bardzo szybki.

Nie musi to jednak zależeć w dużej mierze od JVM. Jeśli jednak okazałoby się, że jest to wąskie gardło w twoim kodzie, uważam implementację JVM za raczej słabą. Nawet taki, który nie ma kompilatora JIT i tylko interpretuje kod, powinien być w stanie wykonać instancję testu praktycznie w mgnieniu oka.

Wrócę do ciebie na podstawie wystąpienia. Ale sposobem na uniknięcie problemu (lub jego braku) byłoby stworzenie interfejsu nadrzędnego dla wszystkich podklas, na których należy wykonać instanceof. Interfejs będzie super zestawem wszystkich metod w podklasach, dla których należy wykonać instancję sprawdzania. Jeżeli metoda nie ma zastosowania do konkretnej podklasy, wystarczy podać fikcyjną implementację tej metody. Jeśli nie zrozumiałem problemu, w ten sposób udało mi się obejść problem w przeszłości.

InstanceOf jest ostrzeżeniem o złym projektowaniu obiektowym.

Obecne maszyny JVM oznaczają, że instanceOf sam w sobie nie stanowi problemu z wydajnością. Jeśli często go używasz, szczególnie w przypadku podstawowych funkcji, prawdopodobnie czas przyjrzeć się projektowi. Wzrost wydajności (i prostoty / łatwości konserwacji) dzięki refaktoryzacji do lepszego projektu znacznie przewyższy wszelkie rzeczywiste cykle procesora spędzone na rzeczywistej instancji wywołaniu .

Aby dać bardzo mały uproszczony przykład programowania.

if (SomeObject instanceOf Integer) {
  [do something]
}
if (SomeObject instanceOf Double) {
  [do something different]
}

Czy w przypadku złej architektury lepszym wyborem byłoby, gdyby SomeObject był klasą nadrzędną dwóch klas podrzędnych, w których każda klasa podrzędna przesłania metodę (doSomething), aby kod wyglądał następująco:

Someobject.doSomething();

W nowoczesnej wersji Java operator instanceof jest szybszy jako proste wywołanie metody. To znaczy:

if(a instanceof AnyObject){
}

jest szybszy, ponieważ:

if(a.getType() == XYZ){
}

Inną sprawą jest konieczność kaskadowania wielu instancji. Następnie przełącznik, który wywołuje tylko raz getType (), jest szybszy.

Jeśli jedynym celem jest szybkość, to użycie stałych int do identyfikacji podklas wydaje się zabijać milisekundy czasu

static final int ID_A = 0;
static final int ID_B = 1;
abstract class Base {
  final int id;
  Base(int i) { id = i; }
}
class A extends Base {
 A() { super(ID_A); }
}
class B extends Base {
 B() { super(ID_B); }
}
...
Base obj = ...
switch(obj.id) {
case  ID_A: .... break;
case  ID_B: .... break;
}

okropny projekt OO, ale jeśli analiza wydajności wskazuje, że to jest wąskie gardło, być może. W moim kodzie kod wysyłki zajmuje 10% całkowitego czasu wykonania, co może przyczynić się do poprawy całkowitej prędkości o 1%.

Powinieneś zmierzyć / profil, jeśli to naprawdę problem z wydajnością w twoim projekcie. Jeśli tak, polecam przeprojektowanie - jeśli to możliwe. Jestem prawie pewien, że nie da się pobić natywnej implementacji platformy (napisanej w C). W takim przypadku należy również rozważyć wielokrotne dziedziczenie.

Powinieneś powiedzieć więcej o problemie, być może możesz skorzystać ze sklepu asocjacyjnego, np. Mapa <Klasa, Obiekt>, jeśli jesteś zainteresowany tylko konkretnymi typami.

W odniesieniu do uwagi Petera Lawrey'a, że ​​nie potrzebujesz instancji dla klas końcowych i możesz po prostu użyć referencyjnej równości, bądź ostrożny! Chociaż końcowych klas nie można rozszerzyć, nie ma gwarancji, że zostaną załadowane przez ten sam moduł ładujący klasy. Używaj x.getClass () == SomeFinal.class lub jego podobnej postaci, jeśli masz absolutną pewność, że dla tej sekcji kodu jest tylko jeden moduł ładujący klasy.

Wolę także podejście wyliczeniowe, ale użyłbym abstrakcyjnej klasy bazowej, aby zmusić podklasy do wdrożenia getType()metody.

public abstract class Base
{
  protected enum TYPE
  {
    DERIVED_A, DERIVED_B
  }

  public abstract TYPE getType();

  class DerivedA extends Base
  {
    @Override
    public TYPE getType()
    {
      return TYPE.DERIVED_A;
    }
  }

  class DerivedB extends Base
  {
    @Override
    public TYPE getType()
    {
      return TYPE.DERIVED_B;
    }
  }
}

Pomyślałem, że warto podać kontrprzykład na ogólny konsensus na tej stronie, że „instanceof” nie jest wystarczająco drogi, aby się martwić. Odkryłem, że mam trochę kodu w wewnętrznej pętli, co (w jakiejś historycznej próbie optymalizacji)

if (!(seq instanceof SingleItem)) {
  seq = seq.head();
}

gdzie wywołanie head () na SingleItem zwraca wartość bez zmian. Zastąpienie kodu przez

seq = seq.head();

daje mi przyspieszenie od 269 ms do 169 ms, pomimo faktu, że w pętli dzieje się kilka dość ciężkich rzeczy, takich jak konwersja strun do podwójnych. Możliwe jest oczywiście, że przyspieszenie jest bardziej spowodowane wyeliminowaniem gałęzi warunkowej niż wyeliminowaniem samego operatora instanceof; ale pomyślałem, że warto o tym wspomnieć.

Skupiasz się na złej rzeczy. Różnica między instanceof a jakąkolwiek inną metodą sprawdzania tego samego prawdopodobnie nie byłaby nawet mierzalna. Jeśli wydajność ma kluczowe znaczenie, Java prawdopodobnie jest niewłaściwym językiem. Głównym powodem jest to, że nie możesz kontrolować, kiedy maszyna wirtualna zdecyduje, że chce zbierać śmieci, co może doprowadzić procesor do 100% przez kilka sekund w dużym programie (MagicDraw 10 był do tego świetny). Jeśli nie masz kontroli nad każdym komputerem, na którym ten program będzie działał, nie możesz zagwarantować, na której wersji JVM będzie on włączony, a wiele starszych miało poważne problemy z prędkością. Jeśli jest to mała aplikacja, możesz być w porządku z Javą, ale jeśli ciągle czytasz i odrzucasz dane, to zrobisz to zauważyć, gdy kopnięcia w GC.