Czy oferujesz okres, w którym każdy może wypróbować jakieś pomysły, aby przyspieszyć działanie oprogramowania?

Czasami sztuczki wydajności oprogramowania można znaleźć na podstawie metodologicznego i dokładnego wyszukiwania. Czasami potrzeba rozbieżnego myślenia i odwagi, aby wypróbować szalone pomysły. Czasami pomysł to dopiero początek, któremu należy poświęcić dużo ciężkiej pracy.

Jak wspomóc okres, w którym każdy może wypróbować różne pomysły, aby poprawić wydajność oprogramowania, nad którym pracujemy? Wszyscy członkowie zespołu mają co najmniej kilkumiesięczne doświadczenie z oprogramowaniem i są w tym bardzo dobrzy.

Czy zgadzasz się, że rozbieżne myślenie pomoże znaleźć sposoby na poprawę wydajności oprogramowania? Dlaczego? Dlaczego nie?

Jakie techniki pozwolą nam szybko wypróbować pomysł optymalizacji? Czy wymagana jest szybka prędkość kodowania, aby uzyskać dobre wyniki po wypróbowaniu?

Wreszcie, ile „czasu” należy przeznaczyć, aby zapewnić dobre wyniki bez stwarzania możliwości zwolnienia?

Czy eksperymenty są konieczne, aby udowodnić, że istnieje „szybszy sposób na zrobienie czegoś”? (Dodano 2011-06-07)

Związane z:

• Jakie są twoje strategie, aby podnieść poziom swojego zespołu w sprytny sposób?
• Kiedy włamania do kodu stają się złe?

( Tylko dla celów nagród -2011/06/07 wielkość zespołu wynosi 2-4 programistów, bez dedykowanej kontroli jakości. Cały kod, testy jednostkowe i testy wydajności wykonywane przez programistów. Ze względu na charakter projektu, wyniki profilera są przydatne do pokazania proporcjonalny czas wykonania, nawet jeśli nie ujawnia ani jednego wąskiego gardła.)

Najlepszym rozwiązaniem jest identyfikacja hotspotów za pomocą narzędzia do profilowania i - jako zespół - omawianie sposobów ich naprawy.

Musisz być w stanie zmierzyć i udokumentować poprawę (więc nie jest to zwykłe zgadywanie), a robienie tego jako zespół zapewnia, że ​​ludzie wiedzą, co jest naprawiane i jak.

Programiści hakują dziko w bazie kodu, próbując pomysłów, co oznacza, że ​​nie masz kontroli nad tym, co się dzieje i czy to działa.

Programiści zazwyczaj są inteligentni i kreatywni (ponieważ są to warunki wstępne, aby być dobrym w programowaniu), więc zawsze dobrze jest pozwolić im wypróbować szeroki zakres pomysłów podczas rozwiązywania problemów. Są jednak dwie rzeczy, o których należy pamiętać, próbując poprawić wydajność (zakładam, że „wydajność” oznacza zmniejszenie szybkości wykonywania):

• Optymalizacje algorytmiczne zwykle działają znacznie lepiej niż cokolwiek innego. Jako trywialny przykład, cokolwiek zrobisz z implementacją bubbleort, przy wystarczającej liczbie bardzo ekstremalnie wolna implementacja quicksort w końcu będzie szybsza.
• Robienie czegokolwiek związanego z wydajnością jest całkowicie bezsensowne, chyba że mierzysz (profilujesz) i opierasz wszystko na wynikach.

Najważniejsze jest to, że zanim zaczniesz okres dzikich eksperymentów, upewnij się, że jesteś na tej samej stronie ze wszystkimi, co dotyczy tych rzeczy . Zawsze wstydem jest dowiedzieć się później, że twoi mniej doświadczeni współpracownicy próbowali rzeczy, które nigdy nie mogłyby zadziałać (i mogłeś im to powiedzieć z góry).

Niestety nie mogę mówić z doświadczenia. Ale słyszałem, że Atlassian ma jeden dzień, w którym pracownicy mogą robić swoje, cokolwiek chcą, i prezentować swoje pomysły w rodzaju imprezowej atmosfery. Najwyraźniej wyszło im to dobrze. Ale musiałbym się zgodzić z Andersenem i powiedzieć, że jeśli chodzi o wydajność, kreatywne i gotowe pomysły są mniej ważne niż profilowanie, które procesy zajmują najwięcej czasu. Być może po wyprofilowaniu systemu możesz dać każdemu dzień na wymyślenie pomysłów na przyspieszenie ważnych etapów procesu. Po przedstawieniu swoich pomysłów możesz wybrać, które z nich wypróbować.

Jedną z udanych praktyk, które przeprowadziliśmy w niektórych moich poprzednich zespołach, była koncepcja Deep Dives. Kilku ludzi zbiera się w sali konferencyjnej, określa scenariusz dla użytkownika i po prostu zaczyna krok po kroku lub przegląda logi profilera. W niektórych przypadkach dane wyraźnie pokazały wąskie gardła, które pozwoliły nam przekonać sceptyków, że w ich własnym kodzie naprawdę były problemy z perf! Aby osiągnąć sukces, przestrzegaliśmy kilku kluczowych zasad:

1. Spróbuj skoncentrować się na krytycznych scenariuszach lub ścieżkach kodu, w których podejrzewa się wąskie gardła. Nie marnuj czasu na optymalizację rzeczy, które nie wymagają optymalizacji (jeśli nie są zepsute ...)
2. Utrzymuj grupę małą i skoncentrowaną na ludziach, którzy znają kod najlepiej. Nie zapomnij dołączyć testera i menedżera programu tej funkcji - mają oni kluczowe informacje i mogą skorzystać z uczestnictwa lub gromadzenia informacji o tym, jak mogą lepiej testować.
3. Rozpocznij sesję od poproszenia właściciela obszaru o schemat blokowy wysokiego poziomu i przegląd obszaru. Jakie są kluczowe elementy i krótko opisz, co robią. Będziesz zaskoczony, ile razy schemat blokowy nie odzwierciedlał rzeczywistości po wkopaniu w kod. (Rzeczywisty cytat: „Nie wiedziałem, że nadal korzystamy z tego komponentu. Myślałem, że pozbyliśmy się tego lata temu!”)
4. Spodziewaj się znaleźć błędy funkcjonalne, a także problemy z perf. To dobra rzecz. Spodziewaj się również, że czasami nie znajdziesz nic znaczącego. To też może być dobra rzecz.
5. Spodziewaj się kilku długich sesji. To są spotkania robocze. Usiądź wygodnie i pracuj przez to. Robisz o wiele więcej, gdy wszyscy mogą współpracować w przypadku dłuższych odcinków.
6. Rób notatki, dobre notatki. Jeśli korzystasz z bazy danych śledzenia defektów, rozważ natychmiastowe otwarcie problemów, aby je śledzić, nawet jeśli mają niski priorytet.

Unikaj angażowania całego zespołu w „Performance Push”. Zwykle nie mają wyników, których kierownictwo oczekuje z powodów, o których Thorbjørn Ravn Andersen wspomniał w innej odpowiedzi. W niektórych obszarach zyskasz duże zyski, w innych nie ma regresji, a trudno jest przewidzieć / śledzić, ile korzyści powinieneś powiedzieć „gotowe”. To trudna rozmowa z zarządem.

Powodem, dla którego możesz potrzebować poprawić szybkość oprogramowania, jest to, że coś w nim jest zauważalnie wolne. Jeśli tak nie jest, optymalizacja to strata czasu. Ale jeśli coś jest powolne, wykonaj zadanie.

... Aby wykonać zadanie, są dwa kroki w tej kolejności:

1. Sprawdź, czy funkcja wykonująca zadanie jest skutecznie napisana. Czy ma dobry czy zły algorytm? Czy skutecznie uzyskuje dostęp do bazy danych? Czy zapętla się 100 razy, kiedy może to zrobić? Często prosta kontrola kodu może znaleźć jedną przeszkodę i nie tylko ją naprawić, ale jednocześnie uczynić cię lepszym programistą.

2. Nie wydawaj więcej niż godzinę na numer 1. Jeśli nie możesz znaleźć problemu w ciągu godziny, użyj profilera, aby znaleźć dane miejsce. Gdy poznasz problem, możesz wrócić do numeru 1 i zrobić to jeszcze raz, starając się znaleźć najlepszy sposób na poprawienie zidentyfikowanego kodu.

Ogólnie (**) eksperymentowanie nie daje lepszej wydajności.

Rozumiesz

• Wiedząc, jak stworzyć prosty, wydajny projekt na początek. Jeśli pomylisz się, ta część eksperymentu nie zrobi dużej różnicy. Na przykład, wiedz, jak powiedzieć, kiedy użycie generatora kodu jest zwycięskim podejściem projektowym.

• Wiedząc, jak dostroić oprogramowanie, lokalizując działania, które są a) procentowe i b) wymienne na coś lepszego. Wszyscy wiedzą, że powinieneś „użyć profilera”, ale to nie wystarczy.

Sprawdź tę odpowiedź na inne pytanie.

** Wyjątkiem może być ścisły kod zależny od sprzętu, taki jak renderowanie grafiki, potok procesora lub zachowanie CUDA, lub eksperymentowanie z protokołami sieciowymi lub DB, gdzie wystarczy zapoznać się z najlepszym sposobem korzystania z niego.

DODANO: Jest coś, co zaskakuje wielu programistów dużych systemów. W dużych doskonale doskonale skonstruowanych programach mogą występować duże, niewidoczne problemy z wydajnością, a profilerzy nie mogą ich znaleźć, ponieważ nie są zlokalizowani w procedurach. Są one częścią ogólnej struktury programu, nawet jeśli program może być wykonany w najlepszym stylu.

Podając konkretny przykład, oto program z kodem źródłowym (w C ++), który wykonuje zadanie. Jest destylowany z prawdziwego programu C, nad którym pracowałem.

Robi to, co było zamierzone, ale jaka część jego czasu nie jest tak naprawdę konieczna? Jak bardzo można to przyspieszyć?

Cóż, w pierwszej wersji programu coś doskonale rozsądnego i nielokalnego (niewidoczne dla profilera) zajmowało 33,3% czasu. Kiedy został wymieniony, ten czas został zaoszczędzony i była to druga wersja programu.

W drugiej wersji programu coś innego (niewidocznego dla żadnego profilera), które można było usunąć, zajmowało 16,7% czasu. Usunięcie go doprowadziło do wersji 3.

W wersji 3 usunięto 13%. Z tego, co zostało, usunięto 66%. Z tego, co zostało po tym, 61% zostało usuniętych!

Wreszcie, z tego, co zostało po tym, 98% zostało usunięte!

Więc jaki jest duży obraz? Na każde 1000 cykli wydanych przez oryginalny program, ile zostało usuniętych? 998!

Każdy program jest inny, ale z mojego doświadczenia wynika, że ​​każdy duży program wiąże się z szeregiem czasochłonnych problemów, których profilerzy nie znajdą, ręcznego próbkowania oraz, że jeśli programiści naprawdę dążą do maksymalnej wydajności, można je usunąć dla dużych przyspieszeń.