Ponieważ istnieje ogromna różnica między optymalizacją wydajności a wyłączeniem całkowicie bezpieczeństwa
Zmniejszając liczbę GC, ich struktura jest bardziej responsywna i może działać (przypuszczalnie) szybciej. Teraz optymalizacja dla śmieciarza nie oznacza, że nigdy nie robią śmieci. Oznacza to po prostu, że robią to rzadziej, a kiedy to robią, działa to naprawdę szybko. Tego rodzaju optymalizacja obejmuje:
- Minimalizowanie liczby obiektów, które przenoszą się na przestrzeń ocalałych (tj. Które przetrwały co najmniej jeden zbiór śmieci) za pomocą małych obiektów wyrzucanych. Obiekty, które przeniosły się w przestrzeń ocalałych, są trudniejsze do zebrania, a wywóz śmieci tutaj czasami oznacza zamrożenie całej JVM.
- Nie przydzielaj zbyt wielu obiektów na początek. Może się to zdarzyć, jeśli nie będziesz ostrożny, ponieważ obiekty młodego pokolenia są super tanie w przydzielaniu i zbieraniu.
- Upewnij się, że nowy obiekt wskazuje stary (a nie na odwrót), aby młody obiekt był łatwy do zebrania, ponieważ nie ma odniesienia do nich, które spowodowałoby, że byłyby przechowywane
Kiedy wyłączysz wydajność, zazwyczaj dostroisz bardzo specyficzny „gorący punkt”, ignorując kod, który nie jest często uruchamiany. Jeśli zrobisz to w Javie, możesz pozwolić, aby śmieciarz nadal zajmował się tym ciemnym rogiem (ponieważ nie zrobi to dużej różnicy), jednocześnie optymalizując bardzo ostrożnie dla obszaru, który działa w ciasnej pętli. Możesz więc wybrać, gdzie chcesz zoptymalizować, a gdzie nie, a tym samym skoncentrować swój wysiłek tam, gdzie to ważne.
Teraz, jeśli całkowicie wyłączysz śmieci, nie będziesz mógł wybrać. Musisz ręcznie pozbyć się każdego obiektu, zawsze. Ta metoda jest wywoływana co najwyżej raz dziennie? W Javie możesz na to pozwolić, ponieważ jego wpływ na wydajność jest znikomy (może pozwolić na to, aby pełny GC pojawiał się co miesiąc). W C ++ nadal wyciekają zasoby, więc musisz zająć się nawet tą niejasną metodą. Musisz więc płacić cenę za zarządzanie zasobami w każdej pojedynczej części aplikacji, podczas gdy w Javie możesz się skupić.
Ale jest coraz gorzej.
Co się stanie, jeśli masz błąd, powiedzmy w ciemnym rogu aplikacji, do której dostęp jest dostępny tylko w poniedziałek w pełni księżyca? Java ma silną gwarancję bezpieczeństwa. Niewiele jest „niezdefiniowanych zachowań”. Jeśli użyjesz czegoś niewłaściwego, zgłoszony zostanie wyjątek, program się zatrzyma i nie nastąpi uszkodzenie danych. Jesteś więc pewien, że nic złego się nie stanie bez Twojej uwagi.
Ale w czymś takim jak D, możesz mieć zły dostęp do wskaźnika lub przepełnienie bufora i możesz uszkodzić swoją pamięć, ale twój program nie będzie wiedział (wyłączyłeś bezpieczeństwo, pamiętasz?) I będzie działał z niepoprawnym danych i róbcie dość paskudne rzeczy i niszczcie swoje dane, a wy nie wiecie, a gdy więcej korupcji się zdarza, wasze dane stają się coraz bardziej błędne, a potem nagle się psują, i to było w krytycznej dla życia aplikacji, i jakiś błąd wydarzyło się w obliczeniach rakiety, i tak to nie działa i rakiety wybuch, a ktoś umrzeć, a firma jest na pierwszej stronie każdej gazety i punkt szef jej palec do ciebie mówiąc: „Ty jesteś inżynier, który zasugerował, że użyliśmy D do optymalizacji wydajności, dlaczego nie pomyślałeś o bezpieczeństwie?". To twoja wina. Zabiłeś tych ludzi głupią próbą działania.
OK, ok, przez większość czasu jest to znacznie mniej dramatyczne. Ale nawet aplikacja o znaczeniu krytycznym dla biznesu lub po prostu aplikacja GPS lub, powiedzmy, rządowa witryna opieki zdrowotnej może mieć dość negatywne konsekwencje w przypadku błędów. Bardzo dobrym pomysłem jest używanie języka, który albo całkowicie im zapobiegnie, albo szybko się nie powiedzie.
Wyłączenie bezpieczeństwa kosztuje. Być rodzimym nie zawsze ma sens. Czasami jest o wiele prostsze i bezpieczniejsze po prostu zoptymalizować nieco bezpieczny język, który pasuje do języka, w którym możesz strzelać sobie w stopę przez długi czas. Poprawność i bezpieczeństwo w wielu przypadkach przebija kilka nanosekund, które zostałyby złomowane przez całkowite wyeliminowanie GC. W takich sytuacjach można zastosować Disruptor , więc myślę, że LMAX-Exchange wykonał właściwe połączenie.
Ale co w szczególności z D? Masz GC, jeśli chcesz dla ciemnych rogów, a podzbiór SafeD (o którym nie wiedziałem przed edycją) usuwa niezdefiniowane zachowanie (jeśli pamiętasz, aby go użyć!).
W takim razie jest to proste pytanie o dojrzałość. Ekosystem Java jest pełen dobrze napisanych narzędzi i dojrzałych bibliotek (lepszych do programowania). Znacznie więcej programistów zna Javę niż D (lepiej w utrzymaniu). Wybór nowego i mało popularnego języka dla czegoś tak krytycznego jak aplikacja finansowa nie byłby dobrym pomysłem. W przypadku mniej znanego języka, jeśli masz problem, niewielu może ci pomóc, a biblioteki, które znajdziesz, mają zwykle więcej błędów, ponieważ były narażone na mniej ludzi.
Tak więc moja ostatnia uwaga pozostaje ważna: jeśli chcesz uniknąć problemów z tragicznymi konsekwencjami, trzymaj się bezpiecznych wyborów. Na tym etapie życia D jego klientami są małe start-upy gotowe na szalone ryzyko. Jeśli problem może kosztować miliony, lepiej pozostać dalej na krzywej innowacji .