Przede wszystkim nie istnieje założenie, że Integer.toString(i) jest zawsze szybszy niż .
Przede wszystkim, jeśli i jest stałą czasową kompilacji, ""+i będzie również, w przeciwieństwie do String.valueOf(i). Oczywiście, jeśli definicja jest podobna do final int i=16;, czytelnicy sprzeciwi się użyciu ""+i, jako "16" będą znacznie jaśniejsze. Ale jeśli mówimy o final int DEFAULT_USER = DEFAULT_GROUP << GROUP_BIT;, ""+DEFAULT_USER jest o wiele jaśniejsze niż literał zawierający rzeczywistą liczbę. A bycie stałą w czasie kompilacji to coś więcej niż problem z wydajnością, pozwala na użycie ciągu w adnotacjach lub etykietach switch.
Jeśli i nie jest stałą czasu kompilacji, nie ma obowiązkowej postaci skompilowanej, więc w zasadzie kompilatory mogą mimo wszystko kompilować ""+i do Integer.toString(i). Jeśli porównamy zwykłą naiwną (lub nazwijmy to "prosto") implementację new StringBuilder().append("").append(i).toString() z wersją Integer.toString(i) lub hipotetyczną zoptymalizowaną implementacją Java 9, tylko ostatnia akcja kopiowania z bufora StringBuilder do tablicy wartości wyniku String może mieć wpływ na wydajność, ale może to zostać zoptymalizowane przez maszynę wirtualną HotSpot JVM. Druga kwestia, której celem jest rozwiązanie Java 9, początkowa pojemność StringBuilder, nie ma tutaj znaczenia, ponieważ reprezentacja ciągów int z łatwością mieści się w domyślnej pojemności 16char s.
Dla większości nietrywialnych int wartości, koszty konwersji do postaci dziesiętnej będzie przewyższać inne koszty znacznie, więc jeśli wolisz ""+i nad Integer.toString(i) nie należy pozwolić obawy wydajności być powodem, aby go nie używać. Oznacza to również, że nie należy oczekiwać dramatycznego przyspieszenia przy implementacji Java 9. Główna operacja jest wciąż taka sama.
Myślę, że największym ulepszeniem rozwiązania Java 9 jest redukcja rozmiaru kodu o wartości , ponieważ wszystkie te podobne sekwencje wywołania, generowane dla każdego wyrażenia konkatenacji ciągów, będą składane do jednej instrukcji (co jest szczególnie istotne dla konkatenacje wielu wyrażeń). Możliwość poprawy wydajności, to tylko miły dodatek, ale nie spodziewałbym ulepszenia być dramatyczna, a zwłaszcza nie w pierwszych wersjach JRE 9.
Więc decyzja między ""+i i Integer.toString(i) lub String.valueOf(i) jest tylko stylistycznym pytaniem (o czym tu nie mówimy), a nie kwestią wydajności.
Krótszy, tak. Łatwiej zrozumieć? Nie sądzę. 'Integer.parseInt' jest czerwonym śledziem, ponieważ idzie w przeciwnym kierunku - 'String.valueOf (i)' mówi * dokładnie * co robi. Twoim celem nie jest wykonywanie konkatenacji ciągów, więc dlaczego twój kod zawierałby konkatenację ciągów? –
Ulepszona nie oznacza, że jest tak szybka. Osobiście wolę używać '' "+ i' (chyba że jest problem z wydajnością), ale to kwestia gustu. –
" Łatwiej zrozumieć "jest subiektywne. – shmosel