Czy mikro-optymalizacja jest ważna podczas kodowania?

Niedawno zadałem pytanie na temat przepełnienia stosu, aby dowiedzieć się, dlaczego isset () był szybszy niż strlen () w PHP . Rodziło to pytania dotyczące znaczenia czytelnego kodu i tego, czy warto poprawić wydajność mikrosekund w kodzie, czy nawet warto.

Mój ojciec jest emerytowanym programistą i pokazałem mu odpowiedzi. Był absolutnie pewien, że jeśli koder nie bierze pod uwagę wydajności swojego kodu nawet na poziomie mikro, nie są dobrymi programistami.

Nie jestem tego pewien - być może wzrost mocy obliczeniowej oznacza, że ​​nie musimy już brać pod uwagę tego rodzaju ulepszeń mikroprocesorów? Być może tego rodzaju rozważania podejmują ludzie, którzy piszą rzeczywisty kod języka? (PHP w powyższym przypadku).

Czynniki środowiskowe mogą być ważne - Internet zużywa 10% światowej energii. Zastanawiam się, jak marnotrawstwem jest kilka mikrosekund kodu, jeśli powielają się biliony razy na milionach stron internetowych?

Chciałbym poznać odpowiedzi najlepiej oparte na faktach na temat programowania.

Czy mikro-optymalizacja jest ważna podczas kodowania?

Moje osobiste podsumowanie 25 odpowiedzi, dzięki wszystkim.

Czasami musimy naprawdę martwić się mikrooptymalizacjami, ale tylko w bardzo rzadkich przypadkach. Wiarygodność i czytelność są w większości przypadków znacznie ważniejsze. Jednak rozważanie mikrooptymalizacji od czasu do czasu nie zaszkodzi. Podstawowe zrozumienie może pomóc nam nie dokonywać oczywistych złych wyborów podczas kodowania takich jak

if (expensiveFunction() || counter < X)

Powinien być

if (counter < X || expensiveFunction())

( Przykład z @ zidarsk8 ) Może to być niedroga funkcja i dlatego zmiana kodu byłaby mikrooptymalizacją. Ale przy podstawowym zrozumieniu nie musiałbyś, bo w pierwszej kolejności napisałbyś to poprawnie.

Obaj się zgadzam i nie zgadzam z twoim ojcem. Wydajność powinna być brana pod uwagę wcześnie, ale mikrooptymalizacja powinna być rozważana tylko wcześnie, jeśli faktycznie wiesz, że duży procent czasu zostanie spędzony w małych sekcjach kodu związanych z procesorem.

Problem z mikrooptymalizacją polega na tym, że zwykle odbywa się to bez pojęcia, jak programy faktycznie spędzają więcej czasu niż to konieczne.

Ta wiedza pochodzi z doświadczenia w dostrajaniu wydajności, tak jak w tym przykładzie , w którym pozornie prosty program, bez oczywistych nieefektywności, jest przeprowadzany przez szereg etapów diagnozy i przyspieszania, aż jest 43 razy szybszy niż na początku.

Pokazuje to, że tak naprawdę nie można zgadnąć ani zrozumieć, gdzie będą problemy. Jeśli wykonasz diagnozę, która w moim przypadku jest losowo wstrzymywana , wiersze kodu odpowiedzialne za znaczną część czasu są preferencyjnie widoczne. Jeśli na nie spojrzysz, możesz znaleźć kod zastępczy, a tym samym skrócić całkowity czas o mniej więcej tę część.

Inne rzeczy, których nie naprawiłeś, nadal zajmują tyle samo czasu, co wcześniej, ale ponieważ ogólny czas został skrócony, te rzeczy zajmują teraz większy ułamek, więc jeśli zrobisz to wszystko jeszcze raz, tę część można również wyeliminować. Jeśli będziesz to robić przez wiele iteracji, w ten sposób możesz uzyskać ogromne przyspieszenia, bez konieczności dokonywania jakiejkolwiek mikrooptymalizacji .

Po takim doświadczeniu, kiedy podchodzisz do nowych problemów programistycznych, zaczynasz rozpoznawać podejścia projektowe, które początkowo prowadzą do takich nieefektywności. Z mojego doświadczenia wynika, że ​​to nadmierne projektowanie struktury danych, nienormalizowana struktura danych, ogromne poleganie na powiadomieniach, tego typu rzeczy.

Mikrooptymalizacja jest ważna tylko wtedy, gdy liczby mówią, że jest.

Wymagania, które opracowujesz, powinny zawierać specyfikację danych dotyczących wydajności, jeśli wydajność jest w ogóle problemem dla klienta lub użytkownika. Podczas opracowywania oprogramowania powinieneś przetestować wydajność swojego systemu pod kątem tych wymagań. Jeśli nie spełniasz wymagań dotyczących wydajności, musisz wyprofilować bazę kodu i zoptymalizować w razie potrzeby, aby osiągnąć wymagania dotyczące wydajności. Gdy osiągniesz minimalną wymaganą wydajność, nie musisz wyciskać żadnej większej wydajności z systemu, szczególnie jeśli zamierzasz narazić na szwank czytelność i łatwość konserwacji kodu (z mojego doświadczenia wysoce zoptymalizowany kod jest mniej czytelny i łatwe do utrzymania, ale nie zawsze). Jeśli możesz uzyskać dodatkowy wzrost wydajności bez pogorszenia innych atrybutów jakości systemu,

Są jednak przypadki, w których wydajność ma ogromne znaczenie. Myślę głównie w systemach czasu rzeczywistego i systemach wbudowanych. W systemach czasu rzeczywistego zmiana kolejności operacji może mieć ogromny wpływ na dotrzymywanie trudnych terminów wymaganych do prawidłowego działania, a może nawet wpływać na wyniki obliczeń. W systemach wbudowanych zwykle masz ograniczoną pamięć, moc procesora i moc (tak jak w przypadku baterii), więc musisz zmniejszyć rozmiar plików binarnych i zmniejszyć liczbę obliczeń, aby zmaksymalizować żywotność systemu.

Gdy ktoś prosi o optymalizacji , przypomina mi się cytat z Michael A. Jackson

Pierwsza zasada optymalizacji programu: nie rób tego.

Druga zasada optymalizacji programu (tylko dla ekspertów!): Nie rób tego jeszcze .

^{Cytat z Wikipedii poprawiony na angielski brytyjski. * 8 ')}

Implicite w drugą zasadą jest, aby profil kodu i tylko spędzać czas optymalizacji rzeczy, które uczynią różnicę.

Podczas programowania w asercji stwierdzenie twojego ojca było prawidłowe. Ale to jest znacznie bliżej metalu niż większość ludzi programuje obecnie. Dzisiaj nawet próba zoptymalizowania się (bez profilowania) może spowodować spowolnienie działania kodu, niż gdybyś zrobił coś bardziej powszechnego, ponieważ wspólny sposób jest bardziej zoptymalizowany przez nowoczesne kompilatory JIT .

Nawet w C musisz być całkiem dobry w optymalizacji, aby dowiedzieć się więcej o tym, jak zoptymalizować sekcję kodu niż kompilator.

Jeśli nie jesteś zaznajomiony z tym, o czym mówi Ulrich Drepper w swoim znakomitym artykule Co każdy programista powinien wiedzieć o pamięci , to prawdopodobnie przegrywasz nawet próbując się zoptymalizować. Jednak wbrew tytułowi artykułów (który jest hołdem dla równie fantastycznego Davida Goldberga, co każdy informatyk powinien wiedzieć o arytmetyki zmiennoprzecinkowej ) brak takiego poziomu zrozumienia niekoniecznie powstrzymuje cię od bycia dobrym programistą, po prostu innego rodzaju programista.

isset()vs. strlen()w PHP

Nie znam PHP, więc tak naprawdę nie jest oczywiste, co isset()należy zrobić. Mogę wywnioskować to na podstawie kontekstu, ale oznacza to, że będzie on podobnie niejasny dla początkujących programistów PHP, a może nawet spowodować, że bardziej doświadczeni programiści się podniosą. Jest to rodzaj idiomatycznego użycia języka, który może uczynić utrzymanie koszmarem.

Nie tylko, ale nie ma gwarancji, że isset()zawsze będzie bardziej wydajna, tylko dlatego, że jest teraz bardziej wydajna. Optymalizacja może nie być optymalizacją w przyszłym roku lub za 10 lat. Procesory, systemy, kompilatory poprawiają się i zmieniają z czasem. Jeśli wydajność PHP strlen()jest problemem, PHP może zostać zmodyfikowany w przyszłości, wówczas może być konieczne usunięcie wszystkich optymalizacji isset (), aby zoptymalizować kod jeszcze raz.

Każda optymalizacja może stać się przyszłą antyoptymalizacją , dlatego należy ją uznać za możliwy zapach kodu, który należy ograniczyć do minimum.

Przykład z własnego doświadczenia

Jako przykład takiej antyoptymalizacji musiałem kiedyś zdezynfekować ogromną bazę kodu wypełnioną kodem formularza, if x==0 z=0 else z=x*yponieważ ktoś zakładał, że mnożenie zmiennoprzecinkowe zawsze będzie droższe niż gałąź. W oryginalnej architekturze docelowej ta optymalizacja przyspieszyła działanie kodu o rząd wielkości, ale czasy się zmieniają.

Kiedy próbowaliśmy użyć tego kodu na bardziej nowoczesnym procesorze, który był wysoce potokowy, wydajność była przerażająco słaba - każda z tych instrukcji powoduje opróżnienie potoku. Uproszczenie wszystkich tych linii kodu, aby z=x*yprogram działał szybciej o rząd wielkości w nowej architekturze, przywracając wydajność utraconą przez antyoptymalizację .

Problemy, które zwykle musimy optymalizować na dziś, są bardzo różne od problemów , które musieliśmy optymalizować 20 lub nawet 10 lat temu.

Potem martwi robi najwięcej pracy na cykl zegara, teraz jesteśmy bardziej prawdopodobne martwić uderzenia rurociągu, mispredictions branży i tęskni cache na poziomie procesora, ale zamków i komunikacji międzyprocesowej stają się o wiele bardziej znaczące, jak iść do multi- architektury procesowe i wieloprocesorowe. Artykuł Dreppera może naprawdę pomóc w zrozumieniu wielu z tych problemów.

1. Napisz kod, który jest czysty, zwięzły, prosty i zrozumiały.
2. Wykonaj testy wydajności, aby zidentyfikować wąskie gardła.
3. Zoptymalizuj krytyczne sekcje.

Zasadniczo: 95% kodu jest uruchamiane przez 5% czasu. Optymalizacja nie ma sensu przed profilowaniem / testowaniem kodu i sprawdzaniem, które 5% są uruchamiane w 95% przypadków.

Każdy idiota może przeprowadzić mikrooptymalizację, a każdy przyzwoity kompilator / środowisko wykonawcze zrobi to za Ciebie.
Optymalizacja dobrego kodu jest banalna. Pisanie zoptymalizowanego kodu i próba jego poprawienia po tym jest nużące, aw najgorszym nie do utrzymania.

Jeśli poważnie zależy Ci na wydajności, nie używaj PHP do kodu krytycznego dla wydajności. Znajdź wąskie gardła i przepisz je z rozszerzeniami C. Nawet mikrooptymalizacja kodu PHP poza punktem zaciemnienia nie zapewni Ci prawie tak dużej prędkości.

Osobiście bardzo lubiłem robić mikrooptymalizację, kiedy zaczynałem programować. Ponieważ to oczywiste. Ponieważ nagradza cię szybko. Ponieważ nie musisz podejmować ważnych decyzji. To idealny sposób na zwlekanie. Pozwala uciec od naprawdę ważnych części tworzenia oprogramowania: projektowania skalowalnych, elastycznych, rozszerzalnych, solidnych systemów.

Zgadzam się z twoim ojcem: „Jeśli programista nie bierze pod uwagę wydajności swojego kodu nawet na poziomie mikro, nie jest dobrym programistą”. Kluczem jest „rozważenie wydajności”. Nie jest to równoważne z „przeprowadzaniem mikrooptymalizacji na każdym etapie”.

Zgadzam się z większością innych komentarzy - co kiedyś przyspieszało działanie programów C, dziś może tego nie robić - ale należy wziąć pod uwagę inne poważne kwestie: Czy powinienem używać C lub C ++? Klasy z prostymi przeciążonymi operatorami mogą zabić wydajność, jeśli często ich używasz. Czy to ma znaczenie? To zależy od twojej aplikacji, ale jeśli nawet NIE UWAŻASZ, nie jesteś bardzo dobrym programistą. Niektórzy ludzie mogą to rozważyć przez około 2 milisekundy i odrzucić, ale myślę, że zbyt wielu dosłownie nawet tego nie rozważa.

Rzeczywistość jest taka, że ​​dzięki optymalizacji kod może być trudniejszy do odczytania. Napisanie kodu zajmie więcej czasu. Kod znajdzie się gdzieś pomiędzy trochę szybciej a rzędem wielkości szybciej (to rzadkość). Twoi klienci prawdopodobnie nie znają różnicy.

Inną rzeczywistością jest to, że ludzie lubią ponownie wykorzystywać kod, a jego miejsce może być zupełnie inne niż wtedy, gdy go napisałeś. Nagle ludzie mogą się tym przejmować.

Na przykład powiedz, że napisałeś coś w stylu Angry Birds na PC lub na konsolę do gier. Zignorowałeś optymalizację w swoim systemie fizyki i systemie graficznym - ponieważ podwójne rdzenie 2,5 GHz są obecnie w zasadzie minimum, a gra działa wystarczająco dobrze. Potem pojawiają się smartfony i chcesz je przenieść. O rany, rdzeń ARM 600 MHz ?

Pomyśl o stronie internetowej - coś połączonego w weekend, na przykład Hot or Not . Używasz dowolnej bazy danych, pisz wszystko z myślą o szybkim rozwoju, uruchamiaj, wysyłając do znajomych adres URL. Trzy miesiące później twój serwer umiera z powodu przeciążenia i nie możesz nic zrobić, aby go skalować. To się zdarza cały czas. Największe strony internetowe mają rachunki za prąd mierzone w setkach kilowatów, a nawet megawatów. Pomyśl o tym, istnieją megawaty do zapisania dzięki optymalizacji kodu.

Tak jak powiedział twój ojciec, musisz przynajmniej to rozważyć . Większość ludzi nawet nie wie, ile wydajności jest na stole i rzuca na nią okiem szybkim żartem o „przedwczesnej optymalizacji” i „nie rób tego”. To nie są dobrzy programiści.

To nie jest popularna opinia na tych stronach. Do zobaczenia punkty reputacji ....

Najpierw weźmy twoją sprawę: PHP

• Nie sądzę, że PHP jest rodzajem języka (zarówno ze względu na jego naturę, jak i główną domenę aplikacji), że trzeba się martwić o te „mikrooptymalizacje”. Kod PHP jest głównie zoptymalizowany z buforowaniem opcode.
• Programy napisane w PHP nie są powiązane z procesorem, są głównie związane z operacjami wejścia / wyjścia , więc te optymalizacje i tak nie będą warte twojego czasu.
• Wszystko, co MUSISZ zoptymalizować, powinno prawdopodobnie zostać wciągnięte do rozszerzenia C, a następnie dynamicznie załadowane do środowiska wykonawczego PHP
• Jak widać, nie otrzymujemy zachęty, jeśli mikrooptymalizujemy nasz kod w PHP - z drugiej strony, jeśli poświęcisz ten czas na uczynienie kodu PHP bardziej czytelnym i łatwym w utrzymaniu - to przyniesie ci więcej dywidend.

Ogólnie,

Nie spędzałbym „TOOOOO” dużo czasu na optymalizacji mojego kodu w dynamicznym języku, takim jak Python lub Ruby - ponieważ NIE są one przeznaczone do zadań wymagających dużej liczby procesorów. Rozwiązują różne rodzaje problemów, w których modelowanie rzeczywistej sytuacji w świecie w skomplikowany sposób (który jest łatwy do odczytania i utrzymania) - co nazywa się ekspresją - jest ważniejsze niż szybkość. Gdyby najważniejsza była prędkość, nie byłyby one przede wszystkim dynamiczne.

W przypadku skompilowanych programów (C ++, Java) optymalizacja jest ważniejsza. Ale i tam najpierw musisz spojrzeć na naturę / domenę / cel pisanego programu. Powinieneś także starannie wyważyć czas na mikrooptymalizację w stosunku do zysków z tej optymalizacji. Jeśli potrzebujesz jeszcze większej optymalizacji, równie dobrze możesz rozważyć krok w dół - i zakoduj te fragmenty swojego kodu w asemblerze.

Tak więc, aby odpowiedzieć na twoje pierwotne pytanie - „Czy mikrooptymalizacja jest ważna podczas kodowania?” - odpowiedź brzmi - ZALEŻY -

• Co robisz: domena aplikacji, złożoność?
• Czy ulepszenia szybkości w mikrosekundach NAPRAWDĘ są ważne dla Twojego programu?
• Jaki rodzaj optymalizacji przyniesie największe zyski? Nie zawsze może to być optymalizacja kodu, ale coś zewnętrznego.
• Ile „dobroci” (pod względem prędkości) czerpiesz z czasu, który inwestujesz w mikrooptymalizację?
• Czy można osiągnąć lepsze prędkości na inne sposoby - zmieniając sprzęt, pamięć RAM i procesor, wykonując kod równolegle lub w systemie rozproszonym?

Mikrooptymalizacja (optymalizacja kodu pod tym względem) jest nie tylko czasochłonna, ale „zniekształca” naturalną czytelność kodu, przez co wymaga dużej konserwacji. Zawsze traktuj to jako ostateczność - zawsze staraj się zoptymalizować całą aplikację, przyjmując lepszy sprzęt i lepszą architekturę niż optymalizacja poszczególnych plików kodu.

Wydaje się, że istnieje wiele odpowiedzi, które mówią, że mikrooptymalizacja jest

wszystko o kompromisach - wydajność, czas, koszt, wysiłek, czytelność / konserwacja i tak dalej.

Ale dobrze wiem, że istnieją pewne optymalizacje, które nie mają wpływu na czytelność, i po prostu lubię robić to dla zabawy. Widziałem niektóre z moich zadań szkolnych (wszystkie oparte na szybkości), że zawsze miło jest wziąć pod uwagę mikrooptymalizację podczas pisania instrukcji warunkowych, takich jak:

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

jest zawsze ładniejszy niż

if (shouldDoThis() && counter < X ) 

Istnieje wiele sposobów na „przyspieszenie” takiego kodu, a różnica jest zwykle nieznaczna (choć nie zawsze), ale czuję się lepiej, gdybym tak napisał.

Nie wiem, czy ktokolwiek w ogóle uważa to za optymalizację, ale myślę, że programista powinien wiedzieć i rozważyć te rzeczy podczas pisania swojego kodu.

Na początku mojej kariery ogólne stwierdzenia takie jak „nie mikrooptymalizuj” doprowadziły do ​​wielu nieporozumień. Wszystko jest poszlakowe; dlatego ludzie mówią „najlepsza praktyka” zamiast „rób to”.

„Najlepsza praktyka” jest najlepszym wyborem, biorąc pod uwagę wszystkie okoliczności. Na przykład LINQ i Entity Framework powinny być używane zamiast wbudowanego SQL. W mojej firmie korzystamy z SQL Server 2000 . SQL Server 2000 nie obsługuje Entity Framework. Najlepsze praktyki wymagają:

• Sprzedając mojemu szefowi pomysł zakupu nowej wersji SQL Servera, co oznacza kilka tysięcy dolarów.
• Sprzedawanie programistom pomysłu uczenia się nowych technologii.

Wiem z doświadczenia, że ​​tak się nie stanie. Mogłem więc zrezygnować, stresować się bez końca lub nie stosować najlepszej praktyki.

Decyzje, które wpływają na ogólny wynik, mają względy polityczne, techniczne i monetarne. Pamiętaj o tym przy podejmowaniu decyzji i mądrze wybieraj bitwy.

„ Na wszystko jest pora, czas na każdą czynność pod niebem ”.

To zawsze jest kompromis.

Po pierwsze, w branży komputerowej chodzi przede wszystkim o pieniądze. Jako programista musisz wygenerować wartość dla klienta, aby uzyskać pieniądze (to nadmierne uproszczenie, ale najważniejsze jest tutaj).

Czas programisty kosztuje. Moc maszyny również kosztuje. Zwykle ten drugi koszt jest znacznie niższy niż pierwszy. Jest to więc kapitał, aby mieć czytelny i łatwy do utrzymania kod, dzięki czemu deweloper może spędzać większość czasu na dostarczaniu wartości.

Ważna może być w niektórych przypadkach mikrooptymalizacja. Ale zwykle zawierają mniej czytelny kod lub mniej rozszerzalny kod (nie jest tak w przypadku twojego połączonego przykładu, ale ogólnie tak jest). W pewnym momencie będzie to kosztować deweloper. Tym razem jest droższy niż moc maszyny, jest to strata.

Po drugie, mikrooptymalizacja w dużym projekcie może utrudniać utrzymanie / ewolucję. Problem polega na tym, że podczas ewolucji możliwa jest inna optymalizacja. Dzięki rozwijającej się aplikacji zazwyczaj znajdziesz rozwiązanie wolniejsze niż to, co miałbyś bez przeprowadzania tych optymalizacji.

Po trzecie, optymalizacja jest często nieistotna, ponieważ złożoność algorytmu zazwyczaj przezwycięża wszelkie mikrooptymalizacje, które można by wykonać, gdyby zbiór danych wzrastał. Niestety, ponieważ mikrooptymalizacja utrudnia utrzymanie / ewolucję kodu, optymalizacja może być trudniejsza.

Czasami wartość ma tę optymalizację (pomyśl o programach krytycznych dla opóźnienia, takich jak gry wideo lub autopilot samolotu). Ale trzeba to wykazać. Zazwyczaj twój program spędza większość czasu w ograniczonej części kodu. Niezależnie od tego, jaką zrobisz mikrooptymalizację, nigdy nie dostaniesz programów o wiele szybciej bez zidentyfikowania wąskiego gardła i pracy nad tą częścią.

Zadanie pytania w taki sam sposób, jak pokazano, pokazało, że problem nie został porównany z rzeczywistym programem. W takim przypadku mógłbyś zrobić lewę i zauważyć, czy było szybciej, czy nie. Więc pytałeś o to, zanim miałeś jakiś problem. Tu jest problem. Źle radziłeś sobie z problemem optymalizacji.

Ponieważ konserwacja i ewolucja są zwykle cenniejsze niż mikrooptymalizacja, upewnij się, że masz odpowiedni interfejs przed wykonaniem jakiejkolwiek. Następnie, jeśli części twojego programu są dla siebie wystarczająco abstrakcyjne, możesz je mikro-zoptymalizować bez uszczerbku dla całości. Wymaga to, aby Twój interfejs działał wystarczająco długo, aby można było mu zaufać.

Wydajność to funkcja

Artykuł Jeffa Atwooda jest świetny na temat budowania wysokowydajnej strony internetowej i tego, jak ważne jest to ...

To powiedziawszy, nie koncentruj się na mikrooptymalizacji, dopóki nie będziesz musiał. Można przeprowadzić bardziej opłacalną optymalizację. Skoncentruj się na architekturze, a nie na kodzie. Większość stron internetowych, które widziałem, które działały powoli, miały problemy na wysokim poziomie (niepotrzebna warstwa usług internetowych, zły projekt bazy danych, zbyt skomplikowane architektury), które nie tylko negatywnie wpłynęły na wydajność, ale były głęboko zakorzenione i trudne do naprawienia.

Podczas tworzenia witryny kod po stronie klienta i logika bazy danych znacznie częściej powodują problemy z wydajnością niż kod po stronie serwera. Jakkolwiek, jeśli masz problemy z wydajnością, będziesz wiedzieć, jeszcze lepiej profiluj swój kod i możesz je znaleźć wcześnie.

Czas programisty kosztuje więcej niż czas komputerowy. Zazwyczaj chcesz to zoptymalizować. Ale:

• Istnieje różnica między mikrooptymalizacją a złożonością algorytmiczną. Poświęć wystarczająco dużo czasu, aby mieć pewność, że używasz właściwego algorytmu .
• Upewnij się, że zadajesz właściwe pytanie, select (select count(*) from foo) >= 1to nie to samo, coselect exists(select 1 from foo) .
• niektóre idiomy językowe są popularne po prostu dlatego, że są szybsze, można z nich korzystać, ponieważ większość biegłych użytkowników języka będzie je znać. (twój przykład jest dobrym przykładem).

Co chcesz zoptymalizować?

• Wydajność oprogramowania?
• Niezawodność?
• Wydajność programisty?
• Satysfakcja konsumenta?
• Wydajność energetyczna?
• Konserwowalność?
• Czas na rynek?
• Koszt?

„Optymalizacja” nie zawsze oznacza, że ​​kod działa tak szybko, jak to możliwe. Są chwile, kiedy znalezienie absolutnie najszybszego sposobu na zrobienie czegoś jest ważne, ale tak naprawdę nie jest to tak powszechne w większości kodów. Jeśli użytkownicy nie zauważą różnicy między 50 a 100 mikrosekund, nie ma żadnej różnicy między tymi dwoma kodami, które będą działały tylko sporadycznie. Oto przykład:

Jeśli musisz stale aktualizować wyświetlanie długości danych wejściowych użytkownika i czasu, który zajmuje jedna z dwóch procedur, aby ustalić, że długość jest znacznie mniejsza niż czas między dwoma kolejnymi naciśnięciami klawiszy, to naprawdę nie ma znaczenia, która procedura używasz. Z drugiej strony, jeśli chcesz określić długość miliarda łańcuchów, prawdopodobnie będziesz chciał zwrócić szczególną uwagę na różnice w wydajności między różnymi procedurami. W pierwszym przypadku wolisz pisać kod, który jest łatwy do zrozumienia i weryfikacji; w drugim przypadku możesz chcieć zamienić czytelność na szybkość.

W każdym razie, jeśli zamierzasz zoptymalizować swój kod, powinieneś profilować go przed i po wprowadzeniu jakichkolwiek zmian. Programy w dzisiejszych czasach są na tyle skomplikowane, że często trudno powiedzieć, gdzie są wąskie gardła; profilowanie pomaga zoptymalizować odpowiedni kod, a następnie pokazać, że dokonane optymalizacje naprawdę zadziałały.

Nie powiedziałeś, kiedy twój ojciec przeszedł na emeryturę ani jakiego rodzaju programowania dokonał, ale jego reakcja nie jest zaskakująca. Historycznie pamięć, pamięć dodatkowa i czas przetwarzania były drogie, a czasem bardzo drogie. Obecnie wszystkie te rzeczy stały się bardzo tanie w porównaniu do czasu programisty. Jednocześnie procesory i kompilatory są w stanie zoptymalizować kod w sposób, którego programiści nigdy nie byliby w stanie dopasować. Dni, w których programiści używają małych sztuczek, aby wydać kilka instrukcji maszynowych tutaj i tam w większości już minęły.

Mikrooptymalizacja podczas pisania kodu nie jest ważna. Optymalizacja powinna odbywać się za pomocą profilera, optymalizującego kod tam, gdzie ma to znaczenie.

JEDNAK programista powinien starać się unikać robienia oczywiście głupich rzeczy podczas pisania kodu.

Na przykład nie wykonuj powtarzających się kosztownych operacji w pętli. Zapisz wartość w zmiennej poza pętlą i użyj jej. Nie rób takich rzeczy jak porównania ciągów lub wyrażenia regularne w często wywoływanej funkcji, gdy możesz przejść poziom wyżej, zrobić porównanie i przekształcić je w liczbę całkowitą, odwołanie do funkcji lub klasę pochodną.

Te rzeczy są łatwe do zapamiętania dla doświadczonego programisty i prawie zawsze poprawiają jakość kodu.

Decydując, co zoptymalizować, zawsze pamiętaj o prawie Amdahla . Zobacz link do dokładnej matematyki; ważne jest, aby pamiętać:

Jeśli jedna część twojego programu stanowi 10% czasu jej działania, a Ty zoptymalizujesz tę część, aby działała dwa razy szybciej, program jako całość przyspieszy tylko o 5%.

Dlatego ludzie zawsze mówią, że nie warto optymalizować części programu, które nie zajmują więcej niż kilka procent całkowitego czasu działania. Ale to tylko szczególny przypadek bardziej ogólnej zasady. Prawo Amdahla mówi ci, że jeśli chcesz, aby cały program działał dwa razy szybciej, musisz przyspieszyć każdy kawałek średnio o 50%. Mówi ci, że jeśli potrzebujesz przetworzyć dwadzieścia gigabajtów danych, istnieją tylko dwa sposoby, aby przyspieszyć to niż czas potrzebny do odczytania dwudziestu gigabajtów z dysku: zdobądź szybszy dysk lub zmniejsz dane.

Co więc mówi prawo Amdahla o mikrooptymalizacjach? Mówi, że być może warto, jeśli aplikują na całym forum. Jeśli możesz zmniejszyć o jeden procent czas działania każdej funkcji w programie, gratulacje! Przyspiesziłeś program o jeden procent. Czy było warto? Jako kompilator z przyjemnością znajdę optymalizację, która to zrobiłaby, ale jeśli robisz to ręcznie, powiedziałbym, że szukaj czegoś większego.

To zależy od tego, na jakim etapie rozwoju jesteś, kiedy na początku zaczynasz coś pisać, mikrooptymalizacje nie powinny być brane pod uwagę, ponieważ zamierzasz uzyskać większy wzrost wydajności dzięki zastosowaniu dobrych algorytmów niż przy użyciu mikrooptymalizacji. Zastanów się także nad tym, co opracowujesz, ponieważ aplikacje wrażliwe na czas przyniosą więcej korzyści z uwagi na mikrooptymalizację niż ogólne aplikacje biznesowe.

Jeśli testujesz i rozszerzasz oprogramowanie, mikrooptymalizacje najprawdopodobniej zaszkodzą, ponieważ utrudniają czytanie kodu, a nawet wprowadzają własny unikalny zestaw błędów, które należy naprawić wraz ze wszystkim, co należy naprawić.

Jeśli faktycznie otrzymujesz skargi od użytkowników na powolny kod, być może warto je rozważyć, ale tylko wtedy, gdy wszystko inne zostało rozwiązane, a mianowicie:

• Czy kod jest dobrze napisany?
• Czy aplikacja może uzyskać dostęp do swoich danych bez żadnych problemów?
• Czy można zastosować lepszy algorytm?

Jeśli na wszystkie pytania udzielono odpowiedzi i nadal występują problemy z wydajnością, być może nadszedł czas, aby zacząć korzystać z mikrooptymalizacji w kodzie, ale są szanse, że inne zmiany (tj. Lepszy kod, lepszy algorytm itp.) Przyniosą korzyści większy przyrost wydajności niż mikrooptymalizacja.

Szybkość wykonania jest jednym z wielu czynników wpływających na jakość programu. Często prędkość ma odwrotną korelację z czytelnością / utrzymywalnością. W prawie wszystkich przypadkach kod musi być czytelny dla człowieka, aby można go było zachować. Jedyny czas, w którym czytelność może być zagrożona, jest wtedy, gdy szybkość jest niezbędnym wymogiem. Wymóg, aby kod był szybszy niż pozwala na to pełna czytelność / łatwość konserwacji, prawie nigdy nie ma zastosowania, ale są pewne przypadki, w których tak się stanie. Najważniejszą rzeczą do zapamiętania jest to, że kod mikrooptymalizowany jest często kodem hackującym, więc jeśli gdzieś nie ma określonego wymagania, prawie zawsze jest to zły sposób rozwiązania problemu. Na przykład użytkownik prawie nigdy nie zauważy różnicy między czasami wykonania 0,55 i 1 sekundy w operacjach CRUD, więc nie musisz iść na hackfest w asemblerze, aby dostać się do tego. 5 sekund. Tak, mógłbym latać helikopterem do pracy i byłoby to 10 razy szybsze, ale nie robię tego ze względu na cenę i fakt, że śmigłowiec jest znacznie trudniejszy do latania.Kiedy niepotrzebnie optymalizujesz kod, robisz dokładnie to, co robisz: dodajesz niepotrzebną złożoność i koszty, aby osiągnąć zbędny cel.

Mikrooptymalizacja jest ważna, gdy trafisz na ograniczenie. Ważna może być pamięć, przepustowość, opóźnienie lub zużycie energii. Zauważ, że są to cechy na poziomie systemu; nie musisz (i nie możesz) zoptymalizować każdej funkcji pod każdym względem.

Systemy osadzone częściej wymagają mikrooptymalizacji, ponieważ łatwiej jest trafić w ograniczenia. Jednak nawet tam mikrooptymalizacja prowadzi do tej pory; nie można mikrooptymalizować wyjścia ze złego projektu. Istotą dobrego projektu w systemie jest to, że możesz rozumować cały system. Komponenty wymagające mikrooptymalizacji powinny być starannie wyeksponowane i zoptymalizowane w sposób, który nie wpłynie negatywnie na konstrukcję systemu.

Zwróć uwagę, że małe „wbudowane” systemy mogą być dzisiaj bardzo zbliżone do Vaxen lub PDP-11 z przeszłości, więc te problemy występowały częściej. W nowoczesnym systemie ogólnego przeznaczenia wykonującym nowoczesne ogólne obliczenia komercyjne mikrooptymalizacja jest rzadkością. Jest to prawdopodobnie część tego, dlaczego twój ojciec zajmuje stanowisko, które zajmuje.

Jednak nie ma znaczenia, czy masz do czynienia z nanosekundami, milisekundami, sekundami czy godzinami; problemy są takie same. Muszą być ocenione w kontekście systemu i tego, co próbujesz osiągnąć.

Jest to przykład z ostatniego pytania, na które odpowiedziałem na temat przepełnienia stosu w przypadku, gdy konieczna była mikrooptymalizacja: kodery wideo typu open source dla systemu osadzonego .

Największym problemem związanym z mikrooptymalizacją jest trudność w utrzymywaniu kodu.

Inna kwestia polega na tym, że w zależności od konfiguracji komputera mikrooptymalizacja może mieć gorszą wydajność niż bez „optymalizacji”.

Dokonanie wielu mikrooptymalizacji pochłonie mnóstwo czasu na walkę z czymś, co tak naprawdę nie ma znaczenia.

Lepszym rozwiązaniem jest uczynienie kodu czystszym, łatwiejszym w utrzymaniu, a jeśli wystąpią problemy z wydajnością, uruchom profil, aby dowiedzieć się, co tak naprawdę spowalnia kod. I wiedząc dokładnie, co jest naprawdę złe, możesz to naprawić.

Nie twierdzę, że brak robienia mikrooptymalizacji jest usprawiedliwieniem do pisania głupiego kodu.

Jeśli zaczniesz się martwić o milisekundy, powinieneś rozważyć rezygnację z PHP i zamiast tego użyć C lub asemblera. Nie to, że chciałbym to zrobić, po prostu nie ma sensu omawiać takich liczb i używać języka skryptowego. Czy twój kod i tak często wykonuje iterację z tym poleceniem?

Czynniki środowiskowe są tutaj wykluczone, te serwery i tak działają 24 godziny na dobę, 7 dni w tygodniu, a jeśli faktycznie coś przetwarzają, będzie to miało znaczenie tylko wtedy, gdy to naprawdę zadanie będzie działać bardzo długo.

Najprawdopodobniej światło w twoim biurze i energia, z której korzystały nasze komputery, podczas gdy wszyscy pisaliśmy pytania i odpowiedzi, zużyły znacznie więcej energii niż jakikolwiek rodzaj mikrooptymalizacji, który możesz rozsądnie zastosować w swoich aplikacjach, który kiedykolwiek zaoszczędzi.

Powinieneś wybrać najlepszy, prosty algorytm dla zadania. Powodem, dla którego musi być prosty, jest utrzymanie czytelności kodu. Powodem, dla którego musi być najlepszy, jest unikanie rozpoczynania od złych właściwości środowiska wykonawczego. Nie ślepo wybieraj BubbleSort, gdy wiesz, że będziesz mieć duże zbiory danych. Jest to jednak w porządku dla okazjonalnego rodzaju 10 elementów.

NASTĘPNIE, jeśli liczby profilowania wskazują, że wybór najlepszego, prostego algorytmu nie był wystarczająco dobry, możesz rozpocząć optymalizację (co zwykle stanowi koszt czytelności).

Powiedziałem to już wcześniej i powiem tutaj: „Przedwczesna optymalizacja jest źródłem wszelkiego zła” . To powinna być jedna z zasad w centrum każdego programisty.

Kod może do pewnego stopnia zawsze być szybszy niż obecnie. O ile nie zajmujesz się ręcznym pakowaniem z myślą o konkretnym układzie, zawsze możesz coś zyskać dzięki optymalizacji. Jednakże, chyba że CHCESZ być ręcznym zestawem do wszystkiego, co robisz, musi istnieć cel ilościowy, który po osiągnięciu celu powiesz „to wystarczy” i przestaniesz optymalizować, nawet jeśli wciąż patrzysz rażąco na frajera ty w twarz.

Piękny, elegancki, niezwykle wydajny kod jest bezużyteczny, jeśli nie działa (a przez „work” rozumiem, że generuje oczekiwane dane wyjściowe przy wszystkich oczekiwanych danych wejściowych). Dlatego tworzenie działającego kodu powinno ZAWSZE być priorytetem. Po tym, jak działa, oceniasz wydajność, a jeśli jej brakuje, szukasz sposobów na poprawę, aż do momentu, w którym będzie wystarczająco dobra.

Są pewne rzeczy, które musisz zdecydować z góry, które wpłyną na wydajność; bardzo podstawowe decyzje, takie jak język / środowisko wykonawcze, którego użyjesz do wdrożenia tego rozwiązania. Wiele z nich wpłynie na wydajność o wiele rzędów wielkości w większym stopniu niż połączenie jednej metody z drugą. Szczerze mówiąc, PHP jako język skryptowy jest już hitem wydajności, ale ponieważ bardzo niewiele stron skryptowych jest budowanych od podstaw w C / C ++, jest porównywalne z innymi technologiami, które prawdopodobnie wybierzesz (Java Servlets, ASP.NET itp.).

Następnie rozmiar komunikatu we / wy jest kolejnym co do wielkości zabójcą wydajności. Optymalizacja tego, co czytasz i zapisujesz na dysku twardym, portach szeregowych, potokach sieciowych itp. Zwykle poprawi czas działania programu o wiele rzędów wielkości, nawet jeśli algorytmy operacji we / wy były wydajne. Następnie zmniejsz złożoność samego algorytmu Big-O, a jeśli to absolutnie konieczne, możesz „mikrooptymalizować”, wybierając tańsze wywołania metod i podejmując inne ezoteryczne decyzje na niskich poziomach.

Wspominasz, że twój tata jest emerytowanym programistą. Programiści pracujący w świecie komputerów mainframe musieli bardzo martwić się wydajnością. Pamiętam, jak studiowałem działalność marynarki wojennej USA, w której ich komputer mainframe był ograniczony sprzętowo do 64 KB pamięci na użytkownika. W tym świecie programowania musisz wydobywać każdy możliwy kawałek.

Teraz sprawy wyglądają zupełnie inaczej i większość programistów nie musi się tak bardzo przejmować mikrooptymalizacjami. Jednak programiści systemów wbudowanych nadal tak robią, a osoby korzystające z baz danych nadal bardzo potrzebują kodu zoptymalizowanego.

Kod powinien być napisany, aby był absolutnie jasny o tym, co robi. Następnie, jeśli i tylko jeśli jest zbyt wolny, wróć i przyspiesz go. Kod można zawsze zmienić, aby był szybszy później, jeśli można go zrozumieć - ale powodzenia, aby był wyraźny, jeśli jest szybki.

Ważne jest, jeśli:

1) Życie kogoś zależy od twojego kodu. Funkcja zajmująca 25ms w czyimś monitorze pracy serca jest prawdopodobnie złym pomysłem.

Osobiście podchodzę do dwóch zasad - istnieją mikrooptymalizacje, które możesz zrobić, co nie wpłynie na czytelność - oczywiście chcesz z nich skorzystać. Ale jeśli wpływa to na czytelność, odsuń się - nie dostaniesz dużych korzyści i może potrwać dłużej w debugowaniu na dłuższą metę.

Czy mikro-optymalizacja jest ważna podczas kodowania?

Nie, biorąc pod uwagę, że istnieją platformy takie jak JVM i .NET, w których kod jest napisany dla maszyny wirtualnej, dlatego próba zoptymalizowania wykonania może nie działać tak dobrze, a to, co jest optymalne na pulpicie programisty, niekoniecznie jest takie samo na serwerze. Zobacz, jak daleko od sprzętu niektóre z tych programów wysokiego poziomu znajdują się w innym miejscu. Biorąc pod uwagę różnorodność sprzętu, należy zastanowić się nad tym, jak realistyczna jest optymalizacja kodu dla konkretnych układów, takich jak procesor lub GPU, kiedy nowy model prawdopodobnie pojawi się za mniej niż rok?

Kolejnym pytaniem do rozważenia jest wydajność mierzona za pomocą tego, co mierzy: szybkość wykonania, pamięć użyta do wykonania, szybkość rozwoju nowych funkcji, rozmiar bazy kodu na serwerze w skompilowanych lub zdekompilowanych formularzach, skalowalność, łatwość konserwacji itp. .? Zasadniczo pytanie staje się trywialne, ale nie jestem pewien, jak szeroko chciałeś wziąć wydajność, tak naprawdę może to być prawie wszystko, o ile można ją w jakiś sposób zmierzyć.

Niektóre mikrooptymalizacje mogą działać, a inne mogą nie działać, dlatego można się zastanawiać, jak opłacalne jest wykonywanie takiej pracy w porównaniu z innymi pracami, które mogą być postrzegane jako o wyższym priorytecie, takie jak nowe funkcje lub naprawianie błędów. Drugim pytaniem byłoby, czy aktualizacja sprzętu lub oprogramowania może również złamać niektóre z tych optymalizacji.

Myślę, że istnieje duża różnica między dobrym programowaniem a mikrooptymalizacją.

Jeśli są dwa sposoby wykonania tego samego zadania, jedno jest szybsze od drugiego i oba mają tę samą czytelność, powinieneś użyć szybszego. Zawsze. I to jest dobre programowanie. Nie ma powodu, aby nie używać lepszego algorytmu do rozwiązania problemu. A nawet udokumentowanie tego jest łatwe: podaj nazwę algorytmu, każdy będzie mógł google go znaleźć i znaleźć więcej informacji na temat jego działania.

Dobre algorytmy są już zoptymalizowane. Będą szybkie. Będą małe. Wykorzystają minimalną wymaganą pamięć.

Nawet jeśli korzystasz z nich, twój program wciąż nie ma takiej wydajności, możesz rozważyć mikrooptymalizację. Musisz naprawdę znać język, aby móc mikrooptymalizować.

I zawsze jest miejsce na wydawanie większej ilości pieniędzy na sprzęt. Sprzęt jest tani, programiści są kosztowni . Nie marnuj zbyt wiele czasu / pieniędzy, optymalizując, kiedy możesz po prostu kupić sprzęt.

Czytelność kodu IMHO jest ważniejsza niż mikrooptymalizacja, ponieważ w większości przypadków mikrooptymalizacja nie jest tego warta.

Artykuł o nieoptymalnych mikrooptymalizacjach :

Jak większość z nas, mam dość czytania postów na blogu o niesensownych mikrooptymalizacjach, takich jak zamiana print na echo, ++ $ i na $ i ++ lub podwójne cudzysłowy na pojedyncze cudzysłowy. Dlaczego? Ponieważ 99,999999% czasu jest bez znaczenia. Dlaczego? Ponieważ 99,99% czasu, lepiej zainstaluj akcelerator PHP, taki jak APC, lub dodaj te brakujące indeksy do kolumn bazy danych, lub spróbuj uniknąć 1000 żądań bazy danych, które masz na stronie głównej.

print używa jeszcze jednego kodu operacyjnego, ponieważ faktycznie coś zwraca. Możemy stwierdzić, że echo jest szybsze niż drukowanie. Ale jeden kod operacyjny nic nie kosztuje, naprawdę nic.

Próbowałem na nowej instalacji WordPress. Skrypt zatrzymuje się, zanim zakończy się z błędem „Bus Error” na moim laptopie, ale liczba kodów operacyjnych wynosiła już ponad 2,3 miliona. Wystarczająco powiedziane.

W większości przypadków mikrooptymalizacja oszczędza 1 operację spośród milionów, ale pogarsza czytelność.

Inne odpowiedzi dotyczą pieniędzy. Ale dodam kolejny punkt, w którym należy rozróżnić, co jest przedwczesna optymalizacja / mikrooptymalizacja i napisać kod wykonawczy, który odzwierciedla zrozumienie zachowania konstrukcji języka / frameworka (przepraszam, nie mogłem znaleźć jednego słowa na ostatnie) . Ten ostatni jest dobrą praktyką kodowania i na ogół należy to zrobić!

Wyjaśnię. Zła optymalizacja (odczyt przedwczesna / mikrooptymalizacja) nie występuje, gdy optymalizujesz sekcje kodu bez profilowania, aby wiedzieć, czy tak naprawdę są wąskie gardła. To wtedy, gdy optymalizujesz na podstawie swoich założeń, przesłuchań i zachowań nieudokumentowanych. Jeśli jest to udokumentowane i robi coś w bardziej wydajny / logiczny sposób, jakkolwiek jest mały, nazywam to dobrą optymalizacją . Jak powiedzieli inni, oba z nich mają wady i prawie nie mają żadnych zalet, jeśli chodzi o zarabianie dobrego interesu, ale nadal robię to drugie, a nie pierwsze, jeśli nie całkowicie pogarsza czytelność. Tak, czytelność / konserwacja ma ogromne znaczenie i zależy od tego, gdzie wyznaczasz linię.

Powtórzę argumenty przedstawione przez innych tutaj jako bezcelowość zarówno dobrych, jak i złych optymalizacji:

1. Twoje zależności od konkretnego problemu mogą się zmienić, a czas poświęcony na optymalizację przed ukończeniem logicznej sekcji aplikacji jest stratą czasu. Mam na myśli optymalizację na stosunkowo wczesnym etapie. Dzisiaj masz List<T>i zanim Twoja aplikacja zostanie dostarczona, musisz ją zmienić, LinkedList<T>a teraz wszystkie testy porównawcze były stratą czasu i wysiłku.

2. Przeważnie prawdziwe wąskie gardło twojej aplikacji (odczytane jako mierzalna różnica) może wynosić 5% twojego kodu (głównie SQL), a optymalizacja pozostałych 95% nie daje twoim klientom żadnych korzyści.

3. Zwykle „technicznie” lepiej działający kod oznacza większą szczegółowość, co z kolei oznacza więcej kodu podatnego na błędy, co z kolei oznacza trudniejszą konserwację i więcej czasu, co z kolei oznacza, że ​​zarabiasz mniej pieniędzy.

4. Ślad węglowy, który oszczędzasz na całym świecie dzięki zwiększeniu wydajności o 1%, łatwo zmniejsza się w wyniku gazów cieplarnianych, które Twój zespół będzie musiał emitować podczas debugowania i utrzymywania tego kodu.

Negatywami złej optymalizacji są w szczególności:

1. Często nie zapewnia oczekiwanej wydajności. Zobacz to pytanie na stronie SO, gdzie nie udały się optymalizacje . W rzeczywistości może mieć negatywne skutki. To jest problem z nieudokumentowanym zachowaniem.

2. Zresztą i tak zrobią to w większości nowoczesne kompilatory.

Podam kilka przykładów złej i dobrej optymalizacji:

Źli -

1. użycie mniejszych typów całkowitych zamiast Int32.

2. ++i używane zamiast i++

3. forzamiast foreach(najgorsze, jakie widziałem, całkowicie pokonuje logikę)

4. unikanie zamkniętych zmiennych

   string p;
   foreach (var item in collection)
       p = ...;
   

5. używanie charzamiast łańcucha podczas konkatenacji łańcucha, takie jak:

   string me = 'i' + "me myself"; // something along that line - causes boxing
   

Dobra (ze świata .NET. Powinna być zrozumiała) -

1. Podwójne wyszukiwanie

   if (Dictionary<K, V>.TryGetValue(K, out V))
       do something with V
   

   zamiast

   if (Dictionary<K, V>.ContainsKey(K))
       do something with Dictionary<K, V>[K]
   

2. Załaduj je wszystkie

   DirectoryInfo.EnumerateFiles();
   

   zamiast

   DirectoryInfo.GetFiles();
   

3. Dwustopniowy casting:

   s = o as string;
   if (s != null)
       proceed
   

   zamiast

   if (o is string)
       s = (string)o;
   

4. Jeśli zamówienie nie ma znaczenia

   if (counter < X || expensiveFunction())
   

   zamiast

   if (expensiveFunction() || counter < X)
   

5. Boks

   void M<T>(T o) //avoids boxing
   {
   
   }
   

   zamiast

   void M(object o)
   {
   
   }
   

Jeśli zapytasz mnie, czy dają one zauważalne korzyści w zakresie wydajności, powiedziałbym, że nie. Sugerowałbym jednak, aby ich użyć, ponieważ wynika to ze zrozumienia zachowania tych konstruktów. Po co nawiązywać dwa połączenia, skoro można wykonać tylko 1? Z filozoficznego punktu widzenia jest to dobra praktyka kodowania. I 1 i 3 są również nieco mniej czytelne w ścisłych kategoriach, ale czy mają one przewagę nad czytelnością? Nie, niewiele, więc używam. Teraz to jest klucz - utrzymanie przyzwoitego stosunku wydajności do czytelności. A kiedy to, to chodzi o to, gdzie narysujesz linię.

„Warto” potrzebuje kontekstu, na przykład o ile łatwiej jest pisać, czytać i utrzymywać w porównaniu do tego, o ile szybciej sprawia, że użytkownik jest znacznie bardziej responsywny, interaktywny i wymaga mniej czasu na czekanie.

Zaoszczędzenie kilku groszy na zakup puszki z napojem nie przyniesie mi wiele dobrego, jeśli będę musiał pokonać odległość, aby zaoszczędzić te grosz, szczególnie biorąc pod uwagę, że w dzisiejszych czasach rzadko piję napoje gazowane. Oszczędność kilku groszy na puszkę przy zakupie miliona puszek napojów gazowanych może być ogromną sprawą.

Tymczasem oszczędzając kilka groszy, gdy dwie osoby są tuż obok mnie, a jedna oferuje dokładnie to samo za kilka groszy taniej, a druga nie, a ja wybieram droższą, ponieważ podoba mi się ich kapelusz, wydaje się głupotą pesymizacji.

To, co często uważam za ludzi nazywających „mikrooptymalizacje”, wydaje się być dziwnie pozbawione pomiarów, kontekstu i dyskusji użytkowników, kiedy absolutnie wszystkie trzy powinny rozważyć takie optymalizacje, jeśli nie są trywialne w zastosowaniu. Dla mnie właściwa mikrooptymalizacja dotyczy obecnie takich układów, jak układy pamięci i wzorce dostępu, i chociaż mogą wydawać się „mikro” w centrum uwagi, nie działają one tak naprawdę.

Nie tak dawno temu udało mi się zredukować operację z 24 sekund do 25 milisekund (około 960 razy szybciej), z identycznymi wyjściami (zabezpieczonymi automatycznymi testami), bez zmiany złożoności algorytmicznej, dla skórowania z dyfuzją objętościową poprzez „mikrooptymalizacje” (największa z nich polegała na zmianie układu pamięci, która zmniejszyła się do około 2 sekund, następnie pozostałe rzeczy to SIMD i dalsza analiza braków pamięci podręcznej w VTune oraz pewne dalsze zmiany układu pamięci).

Wolfire wyjaśnia tutaj technikę i zmagał się z wymaganym czasem: http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/

Moja implementacja zdołała to zrobić w milisekundach, gdy starał się sprowadzić ją do mniej niż minuty:

Po „mikrooptymalizowaniu” go z 24 sekund do 25 ms było to przełomem w przepływie pracy. Teraz artyści mogą zmieniać swoje zestawy w czasie rzeczywistym przy ponad 30 klatkach na sekundę, bez czekania 24 sekund za każdym razem, gdy dokonają jakichkolwiek drobnych zmian w swoim urządzeniu. I to faktycznie zmieniło cały projekt mojego oprogramowania, ponieważ nie potrzebowałem już paska postępu i tego rodzaju rzeczy, wszystko stało się interaktywne. Może to być „mikrooptymalizacja” w tym sensie, że wszystkie ulepszenia pojawiły się bez żadnej poprawy złożoności algorytmu, ale w efekcie była to raczej „mega optymalizacja”, która sprawiła, że ​​wcześniej był to bolesny, nieinteraktywny proces w interaktywny w czasie rzeczywistym, który całkowicie zmienił sposób działania użytkowników.

Pomiar, wymagania użytkownika końcowego, kontekst

Naprawdę podobał mi się komentarz Roberta i być może nie udało mi się wskazać tego, co chciałem:

No dalej. Nikt nie będzie argumentował, że taka zmiana nie jest „warta”. Udało ci się wykazać namacalną korzyść; wiele tak zwanych mikrooptymalizacji nie może.

Jest to, pomimo pracy w bardzo krytycznym dla wydajności polu z często wymaganiami czasu rzeczywistego, jedyny raz, kiedy rozważam jakąkolwiek mikrooptymalizację, która wymaga zejścia mi z drogi.

Chciałbym podkreślić nie tylko pomiary, ale także stronę użytkownika. Jestem dziwakiem, ponieważ przyszedłem do mojej bieżącej dziedziny (i wcześniej gamedev) jako użytkownik / fan jako pierwszy, a programista jako drugi. Więc nigdy nie byłem tak podekscytowany zwykłymi rzeczami, które ekscytują programistów, takimi jak rozwiązywanie zagadek technicznych; Uznałem, że to dla nich ciężar, ale przetrwałbym je poprzez sen użytkowników końcowych, który podzieliłem się z innymi użytkownikami. Ale pomogło mi to upewnić się, że jeśli coś zoptymalizuję, miałoby to realny wpływ na użytkowników z rzeczywistymi korzyściami. To moje zabezpieczenie przed mikrooptymalizacją bezcelowo.

Moim zdaniem jest to tak samo ważne, jak profiler, ponieważ miałem kolegów, którzy robili takie rzeczy, jak mikrooptymalizacja podziału kostki na miliard aspektów tylko po to, aby udusić rzeczywiste modele produkcyjne, takie jak postacie i pojazdy. Ich wynik był imponujący w pewnym sensie „tech demo”, ale prawie bezużyteczny dla rzeczywistych użytkowników, ponieważ profilowali, mierzyli i analizowali przypadki, które nie były zgodne z rzeczywistymi przypadkami użycia. Dlatego tak ważne jest, aby najpierw zrozumieć, co jest ważne dla użytkowników, ucząc się myśleć i korzystać z takiego oprogramowania lub współpracując z nimi (najlepiej oba, ale przynajmniej współpracuj z nimi).

Ujmę to w ten sposób - mikrooptymalizacja to proces optymalizacji czegoś, co wcale nie jest wąskim gardłem. Na przykład, jeśli twój program wywołuje dwie funkcje A i B, a wykonanie A zajmuje 100 milisekund, a B zajmuje 2 mikrosekundy, a ty nadal optymalizujesz funkcję B. To nie tylko nie jest ważne, to jest absolutnie złe. Ale funkcja optymalizacji B nazywa się optymalizacją, a nie mikrooptymalizacją. Znaczenie optymalizacji zależy. Powiedz, że nie masz nic innego do roboty, a twój program jest wolny od błędów, więc tak, to ważne. Ale generalnie masz priorytety. Powiedzmy, że musisz dodać / zapisać funkcję C. Jeśli uważasz, że funkcja pisania C przyniesie Ci więcej pieniędzy niż przyspieszenie programu bez tej funkcji, przejdź do optymalizacji. W przeciwnym razie dąż do funkcjonalności. Również, doświadczeni programiści skoncentrowani na wydajności nie poświęcają dużo czasu na optymalizację, po prostu piszą szybkie programy. Przynajmniej wiedzą, jakich narzędzi użyć, a czego nie robić przez lata, robiąc bezsensowne (czytaj mikro) optymalizacje.