Wszystkie próby wydajnego kodu napisanego w czymkolwiek poza złożeniem opierają się bardzo, bardzo w dużej mierze na optymalizacjach kompilatora, poczynając od najbardziej podstawowych, takich jak wydajne przydzielanie rejestrów, aby uniknąć zbędnych rozlewów stosów w każdym miejscu i co najmniej rozsądnie, jeśli nie doskonale, wybór instrukcji. W przeciwnym razie wrócilibyśmy do lat 80., gdzie musieliśmy wszędzie registerpodpowiedzieć i użyć minimalnej liczby zmiennych w funkcji, aby pomóc archaicznym kompilatorom języka C lub nawet wcześniej, gdy gotobyła to przydatna optymalizacja rozgałęziania.
Gdybyśmy nie czuli, że moglibyśmy polegać na zdolności naszego optymalizatora do optymalizacji naszego kodu, wszyscy nadal kodowalibyśmy ścieżki wykonywania krytyczne pod względem wydajności w asemblerze.
To naprawdę zależy od tego, jak niezawodnie czujesz, że można przeprowadzić optymalizację. Najlepszym rozwiązaniem jest profilowanie i analizowanie możliwości posiadanych kompilatorów, a nawet dezasemblacja, jeśli istnieje punkt dostępu, którego nie można ustalić, gdzie wydaje się kompilator. nie udało się dokonać oczywistej optymalizacji.
RVO jest czymś, co istnieje od wieków, a przynajmniej wykluczając bardzo złożone przypadki, jest to coś, co kompilatory niezawodnie stosują się od wieków. Zdecydowanie nie warto obejść problemu, który nie istnieje.
Błąd po stronie polegania na optymalizatorze, bez obaw
Wręcz przeciwnie, powiedziałbym, że błąd polega na tym, że zbyt wiele polega na optymalizacjach kompilatora, a za mało, a ta sugestia pochodzi od faceta, który pracuje w obszarach krytycznych pod względem wydajności, w których wydajność, łatwość konserwacji i postrzegana jakość wśród klientów jest wszystkie olbrzymie rozmycie. Wolałbym, abyś zbyt pewnie polegał na swoim optymalizatorze i znalazł jakieś niejasne przypadki, w których polegałeś zbyt wiele, zamiast polegać zbyt mało i po prostu wyrzucać z siebie przesądne lęki przez resztę życia. To przynajmniej pozwoli ci sięgnąć po profilera i właściwie zbadać, czy rzeczy nie działają tak szybko, jak powinny, i zdobyć po drodze cenną wiedzę, a nie przesądy.
Dobrze się opierasz na optymalizatorze. Tak trzymaj. Nie bądź taki, jak ten facet, który zaczyna jawnie prosić o wstawienie każdej funkcji wywoływanej w pętli, a nawet profilować z powodu błędnego strachu przed niedociągnięciami optymalizatora.
Profilowy
Profilowanie to tak naprawdę rondo, ale ostateczna odpowiedź na twoje pytanie. Problemem dla początkujących, którzy chcą pisać efektywny kod, z którym często się zmagają, jest nie to, co należy zoptymalizować, ale czego nie należy optymalizować, ponieważ rozwijają oni wszelkiego rodzaju błędne przeczucia dotyczące nieefektywności, które - choć ludzko intuicyjne - są błędne obliczeniowo. Rozwijanie doświadczenia z profilerem zacznie naprawdę zapewniać odpowiednią ocenę nie tylko możliwości optymalizacji kompilatorów, na których można śmiało polegać, ale także możliwości (i ograniczeń) sprzętu. Prawdopodobnie jeszcze więcej wartości ma profilowanie w uczeniu się, co nie było warte optymalizacji, niż uczenie się, co było.