Inni odpowiedzieli na to pytanie w odniesieniu do ciasnych pętli, chociaż wydaje się, że między przykładami Rexa Kerra, które skomentowałem, jest oczywista różnica w wydajności.
Ta odpowiedź jest naprawdę skierowana do osób, które mogą rozważyć potrzebę optymalizacji w ciasnej pętli jako wadę projektową.
Jestem stosunkowo nowy w Scali (około roku lub więcej), ale jak dotąd wydaje mi się, że pozwala to odłożyć stosunkowo łatwe wielu aspektów projektowania, wdrażania i wykonania (z wystarczającą ilością czytania w tle i eksperymentowania :)
Funkcje odroczonego projektu:
Funkcje odroczonej implementacji:
Funkcje odroczonego wykonania: (przepraszam, brak linków)
- Wartości leniwych bezpieczne dla wątków
- Pass-by-name
- Monadyczne rzeczy
Według mnie te cechy pomagają nam podążać ścieżką do szybkich, wąskich aplikacji.
Przykłady Rexa Kerra różnią się pod względem odroczonych aspektów egzekucji. W przykładzie Java alokacja pamięci jest odroczona do momentu obliczenia jej rozmiaru, przy czym przykład Scala odracza wyszukiwanie mapowania. Wydają mi się zupełnie innymi algorytmami.
Oto, jak sądzę, odpowiednik jabłka na jabłka w jego przykładzie w Javie:
val bigEnough = array.collect({
case k: String if k.length > 2 && mapping.contains(k) => mapping(k)
})
Brak zbiory pośredniczących, żadnych Optionwystąpień itp ta zachowuje również typ pobierania, dzięki czemu bigEnoughjest to typ Array[File]- Arrayjest collectrealizacja będzie prawdopodobnie robić coś wzdłuż linii co kod Mr Kerr Java robi.
Funkcje odroczonego projektowania, które wymieniłem powyżej, pozwoliłyby również programistom API kolekcji Scala na zaimplementowanie tej szybkiej implementacji zbierania danych specyficznej dla tablicy w przyszłych wersjach bez przerywania API. To jest to, do czego mam na myśli kroczenie ścieżką do prędkości.
Również:
val bigEnough = array.withFilter(_.length > 2).flatMap(mapping.get)
withFilterMetoda Użyłem tutaj zamiast filterpoprawek pośredni problemu gromadzenia ale jest jeszcze kwestia instancja Option.
Jednym z przykładów prostej szybkości wykonywania w Scali jest logowanie.
W Javie możemy napisać coś takiego:
if (logger.isDebugEnabled())
logger.debug("trace");
W Scali to tylko:
logger.debug("trace")
ponieważ parametr wiadomości do debugowania w Scali ma typ „ => String”, o którym myślę jako o funkcji bez parametrów, która jest wykonywana, gdy jest oceniany, ale którą w dokumentacji nazywa pass-by-name.
EDYCJA {Funkcje w Scali są obiektami, więc jest tutaj dodatkowy obiekt. W mojej pracy wartość trywialnego obiektu jest warta wyeliminowania możliwości niepotrzebnego oszacowania komunikatu dziennika. }
To nie przyspiesza kodu, ale zwiększa prawdopodobieństwo, że będzie szybszy i rzadziej będziemy mieć doświadczenie w masowym przeglądaniu i czyszczeniu kodu innych osób.
Dla mnie jest to spójny temat w Scali.
Twardy kod nie potrafi uchwycić, dlaczego Scala jest szybsza, choć trochę to podpowiada.
Uważam, że jest to połączenie ponownego wykorzystania kodu i pułapu jakości kodu w Scali.
W Javie niesamowity kod jest często zmuszany do przekształcenia się w niezrozumiały bałagan, a więc nie jest tak naprawdę opłacalny w przypadku API o jakości produkcyjnej, ponieważ większość programistów nie byłaby w stanie go używać.
Mam duże nadzieje, że Scala pozwoli einsteinom wśród nas na wdrożenie znacznie bardziej kompetentnych API, potencjalnie wyrażonych przez DSL. Podstawowe interfejsy API w Scali są już daleko na tej ścieżce.