.toArray (new MyClass [0]) czy .toArray (new MyClass [myList.size ()])?

Zakładając, że mam ArrayList

ArrayList<MyClass> myList;

I chcę zadzwonić do Array, czy istnieje powód, dla którego warto użyć wydajności

MyClass[] arr = myList.toArray(new MyClass[myList.size()]);

nad

MyClass[] arr = myList.toArray(new MyClass[0]);

?

Wolę drugi styl, ponieważ jest mniej szczegółowy i założyłem, że kompilator upewni się, że pusta tablica tak naprawdę nie zostanie utworzona, ale zastanawiałem się, czy to prawda.

Oczywiście w 99% przypadków nie robi to różnicy w taki czy inny sposób, ale chciałbym zachować spójny styl między moim normalnym kodem i zoptymalizowanymi wewnętrznymi pętlami ...

Wbrew intuicji najszybsza wersja w Hotspot 8 to:

MyClass[] arr = myList.toArray(new MyClass[0]);

Przeprowadziłem mikro-test porównawczy przy użyciu jmh, wyniki i kod są poniżej, pokazując, że wersja z pustą tablicą konsekwentnie przewyższa wersję z predefiniowaną tablicą. Zwróć uwagę, że jeśli możesz ponownie użyć istniejącej tablicy o odpowiednim rozmiarze, wynik może być inny.

Wyniki testów porównawczych (wynik w mikrosekundach, mniejszy = lepszy):

Benchmark                      (n)  Mode  Samples    Score   Error  Units
c.a.p.SO29378922.preSize         1  avgt       30    0.025 ▒ 0.001  us/op
c.a.p.SO29378922.preSize       100  avgt       30    0.155 ▒ 0.004  us/op
c.a.p.SO29378922.preSize      1000  avgt       30    1.512 ▒ 0.031  us/op
c.a.p.SO29378922.preSize      5000  avgt       30    6.884 ▒ 0.130  us/op
c.a.p.SO29378922.preSize     10000  avgt       30   13.147 ▒ 0.199  us/op
c.a.p.SO29378922.preSize    100000  avgt       30  159.977 ▒ 5.292  us/op
c.a.p.SO29378922.resize          1  avgt       30    0.019 ▒ 0.000  us/op
c.a.p.SO29378922.resize        100  avgt       30    0.133 ▒ 0.003  us/op
c.a.p.SO29378922.resize       1000  avgt       30    1.075 ▒ 0.022  us/op
c.a.p.SO29378922.resize       5000  avgt       30    5.318 ▒ 0.121  us/op
c.a.p.SO29378922.resize      10000  avgt       30   10.652 ▒ 0.227  us/op
c.a.p.SO29378922.resize     100000  avgt       30  139.692 ▒ 8.957  us/op

W celach informacyjnych kod:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
public class SO29378922 {
  @Param({"1", "100", "1000", "5000", "10000", "100000"}) int n;
  private final List<Integer> list = new ArrayList<>();
  @Setup public void populateList() {
    for (int i = 0; i < n; i++) list.add(0);
  }
  @Benchmark public Integer[] preSize() {
    return list.toArray(new Integer[n]);
  }
  @Benchmark public Integer[] resize() {
    return list.toArray(new Integer[0]);
  }
}

Podobne wyniki, pełną analizę i dyskusję znajdziesz w poście na blogu Arrays of Wisdom of the Ancients . Podsumowując: kompilator JVM i JIT zawiera kilka optymalizacji, które umożliwiają tanie tworzenie i inicjowanie nowej tablicy o prawidłowym rozmiarze, a tych optymalizacji nie można użyć, jeśli samodzielnie utworzysz tablicę.

Od ArrayList w Javie 5 tablica będzie już wypełniona, jeśli ma odpowiedni rozmiar (lub jest większa). w konsekwencji

MyClass[] arr = myList.toArray(new MyClass[myList.size()]);

utworzy jeden obiekt tablicy, wypełni go i zwróci do "arr". Z drugiej strony

MyClass[] arr = myList.toArray(new MyClass[0]);

utworzy dwie tablice. Drugi to tablica MyClass o długości 0. Jest więc tworzenie obiektu dla obiektu, który zostanie natychmiast wyrzucony. O ile sugeruje kod źródłowy, kompilator / JIT nie może zoptymalizować tego, aby nie został utworzony. Ponadto użycie obiektu o zerowej długości skutkuje rzutowaniem (rzutami) w ramach metody toArray () -.

Zobacz źródło ArrayList.toArray ():

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

Użyj pierwszej metody, aby utworzyć tylko jeden obiekt i uniknąć (niejawnych, ale kosztownych) rzutów.

Z inspekcji JetBrains Intellij Idea:

Istnieją dwa style konwersji kolekcji na tablicę: albo przy użyciu tablicy o ustalonym rozmiarze (np. C.toArray (new String [c.size ()]) ), albo przy użyciu pustej tablicy (np. C.toArray (new String [ 0]) .

W starszych wersjach Javy zalecane było używanie tablic o wstępnie ustalonym rozmiarze, ponieważ wywołanie odbicia, które jest konieczne do utworzenia tablicy o odpowiednim rozmiarze, było dość powolne. Jednak od późnych aktualizacji OpenJDK 6 wywołanie to było zintensyfikowane, sprawiając, że wydajność wersji z pustą tablicą była taka sama, a czasem nawet lepsza, w porównaniu z wersją o wcześniejszym rozmiarze. Również przekazywanie tablicy o wstępnie ustalonym rozmiarze jest niebezpieczne dla zbierania współbieżnego lub zsynchronizowanego, ponieważ wyścig danych jest możliwy między rozmiarem a wywołaniem toArray, co może skutkować dodatkowymi wartościami zerowymi na końcu tablicy, jeśli kolekcja została jednocześnie zmniejszona podczas operacji.

Ta inspekcja pozwala na przestrzeganie jednolitego stylu: albo użycie pustej tablicy (co jest zalecane we współczesnej Javie), albo użycie tablicy o ustalonym rozmiarze (co może być szybsze w starszych wersjach Javy lub maszynach JVM nie opartych na HotSpot).

Nowoczesne maszyny JVM optymalizują w tym przypadku konstrukcję tablicy odblaskowej, więc różnica w wydajności jest niewielka. Dwukrotne nazwanie kolekcji w takim standardowym kodzie nie jest dobrym pomysłem, więc unikałbym pierwszej metody. Kolejną zaletą drugiej jest to, że działa ona z kolekcjami synchronizowanymi i współbieżnymi. Jeśli chcesz dokonać optymalizacji, użyj ponownie pustej tablicy (puste tablice są niezmienne i mogą być współużytkowane) lub użyj profilera (!).

toArray sprawdza, czy przekazana tablica ma właściwy rozmiar (czyli wystarczająco dużą, aby zmieścić elementy z Twojej listy), a jeśli tak, to używa. W konsekwencji, jeśli rozmiar tablicy pod warunkiem, że jest mniejszy niż wymagany, nowa tablica zostanie utworzona odruchowo.

W twoim przypadku tablica o rozmiarze zero jest niezmienna, więc można ją bezpiecznie podnieść do statycznej zmiennej końcowej, co może sprawić, że kod będzie trochę czystszy, co pozwoli uniknąć tworzenia tablicy przy każdym wywołaniu. Nowa tablica i tak zostanie utworzona wewnątrz metody, więc jest to optymalizacja czytelności.

Prawdopodobnie szybszą wersją jest przekazywanie tablicy o odpowiednim rozmiarze, ale jeśli nie możesz udowodnić, że ten kod stanowi wąskie gardło wydajności, preferuj czytelność od wydajności w czasie wykonywania, dopóki nie zostanie udowodnione, że jest inaczej.

Pierwszy przypadek jest bardziej skuteczny.

Dzieje się tak, ponieważ w drugim przypadku:

MyClass[] arr = myList.toArray(new MyClass[0]);

Środowisko wykonawcze faktycznie tworzy pustą tablicę (o rozmiarze zerowym), a następnie wewnątrz metody toArray tworzy kolejną tablicę, aby dopasować rzeczywiste dane. To tworzenie odbywa się za pomocą odbicia przy użyciu następującego kodu (pobranego z jdk1.5.0_10):

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        a = (T[])java.lang.reflect.Array.
    newInstance(a.getClass().getComponentType(), size);
System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

Korzystając z pierwszego formularza, unikasz tworzenia drugiej tablicy, a także unikasz kodu odbicia.

Drugi jest nieznacznie bardziej czytelny, ale poprawa jest tak mała, że ​​nie jest tego warta. Pierwsza metoda jest szybsza i nie ma żadnych wad w czasie wykonywania, więc właśnie tego używam. Ale piszę to w drugi sposób, ponieważ pisanie jest szybsze. Wtedy moje IDE oznacza to jako ostrzeżenie i proponuje naprawienie tego. Jednym naciśnięciem klawisza konwertuje kod z drugiego typu na pierwszy.

Użycie „toArray” z tablicą o odpowiednim rozmiarze będzie działać lepiej, ponieważ alternatywa utworzy najpierw tablicę o rozmiarze zerowym, a następnie tablicę o odpowiednim rozmiarze. Jednak, jak mówisz, różnica będzie prawdopodobnie nieistotna.

Należy również zauważyć, że kompilator javac nie przeprowadza żadnej optymalizacji. Obecnie wszystkie optymalizacje są wykonywane przez kompilatory JIT / HotSpot w czasie wykonywania. Nie znam żadnych optymalizacji dotyczących „toArray” w żadnej JVM.

Odpowiedź na twoje pytanie jest zatem w dużej mierze kwestią stylu, ale ze względu na spójność powinna stanowić część wszelkich standardów kodowania, których się przestrzegasz (udokumentowanych lub innych).

przykładowy kod dla liczby całkowitej:

Integer[] arr = myList.toArray(new integer[0]);