W czasach współczesnych komputerów w „typowych aplikacjach biznesowych” - dlaczego wydajność ma znaczenie? [Zamknięte]


29

To może wydawać się dziwnym pytaniem dla niektórych z was.

Jestem hobbystycznym programistą Java. Opracowałem kilka gier, program AI, który tworzy muzykę, inny program do malowania i podobne rzeczy. To znaczy, że mam doświadczenie w programowaniu, ale nie w profesjonalnym rozwoju aplikacji biznesowych.

Na tej stronie dużo mówi się o wydajności. Ludzie często dyskutują o tym, który algorytm byłby najskuteczniejszy w języku C # do wykonania zadania lub dlaczego Python działa wolno, a Java szybciej itp.

Próbuję zrozumieć: dlaczego to ma znaczenie?

Rozumiem, że istnieją szczególne obszary obliczeń, w których rozumiem, dlaczego wydajność ma znaczenie: gry, w których dziesiątki tysięcy obliczeń odbywają się co sekundę w pętli ciągłej aktualizacji, lub systemy niskiego poziomu, na których polegają inne programy, takie jak systemy operacyjne i maszyny wirtualne itp.

Ale w przypadku normalnej, typowej aplikacji biznesowej na wysokim poziomie, dlaczego wydajność ma znaczenie?

Rozumiem, dlaczego to miało znaczenie, dekady temu. Komputery działały znacznie wolniej i miały znacznie mniej pamięci, więc trzeba było dokładnie przemyśleć te rzeczy.

Ale dzisiaj mamy tak dużo pamięci do stracenia, a komputery są tak szybkie: czy faktycznie ma znaczenie, czy konkretny algorytm Java to O (n ^ 2)? Czy rzeczywiście zrobi to różnicę dla użytkowników końcowych tej typowej aplikacji biznesowej?

Kiedy naciśniesz przycisk GUI w typowej aplikacji biznesowej i za kulisami wywołuje on algorytm O (n ^ 2), w dzisiejszych czasach nowoczesnego komputera - czy faktycznie odczuwasz nieefektywność?

Moje pytanie jest podzielone na dwie części:

  1. W praktyce dzisiaj wydajność ma znaczenie w typowym normalnym programie biznesowym?
  2. Jeśli tak, proszę podać rzeczywiste przykłady miejsc w takiej aplikacji, w których ważna jest wydajność i optymalizacje.


Wydajność ma znaczenie, jeśli jest słaba.
Mike Dunlavey,

Odpowiedzi:


40

Masz rację, wydajność w aplikacjach biznesowych nie jest tak naprawdę ważnym tematem, jak jest omawiana przez większość programistów . Zazwyczaj dyskusje dotyczące wydajności, które słyszę od programistów, mają kilka problemów:

  • Są to głównie przedwczesna optymalizacja . Zwykle ktoś chce „najszybszego sposobu” na wykonanie operacji bez wyraźnego powodu i kończy albo wprowadzanie zmian w kodzie, które i tak są wprowadzane przez większość kompilatorów (takich jak zamiana dzielenia przez mnożenie lub wstawianie metody), lub spędzanie dni na wprowadzaniu zmian co pomoże uzyskać kilka mikrosekund w czasie wykonywania.

  • Często są spekulacyjne . Cieszę się, że w przypadku przepełnienia stosu i Programmers.SE profilowanie jest często wspominane, gdy pytanie dotyczy wydajności, ale jestem rozczarowany, gdy widzę dwóch programistów, którzy nie wiedzą, jakie profilowanie dyskutuje o wydajności powiązane zmiany, które powinni wprowadzić w kodzie. Wierzą, że zmiany spowodują, że wszystko przyspieszy, ale praktycznie za każdym razem albo nie będzie to miało widocznego efektu, ani spowolni rzeczy, a profiler wskazałby je na inną część kodu, którą można łatwo zoptymalizować i która marnuje 80% czasu.

  • Koncentrują się wyłącznie na aspektach technicznych. Wydajność aplikacji zorientowanych na użytkownika polega na odczuciu: czy działa szybko i szybko, czy też jest powolna i niezgrabna? W tym kontekście problemy z wydajnością są zazwyczaj znacznie lepiej rozwiązywane przez projektantów interfejsu użytkownika: proste animowane przejście może często stanowić różnicę między aplikacją, która działa strasznie wolno, a aplikacją, która wydaje się responsywna, podczas gdy obie spędzają 600 ms. robić operację.

  • Opierają się na subiektywnych elementach, nawet jeśli są związane z ograniczeniami technicznymi. Jeśli nie chodzi o to, by czuć się szybko i szybko reagować, powinien istnieć wymóg niefunkcjonalny, który określa, jak szybko należy wykonać operację na określonych danych, działając w określonym systemie . W rzeczywistości dzieje się mniej więcej tak: menedżer mówi, że znajduje coś wolnego, a następnie programiści muszą dowiedzieć się, co to znaczy. Czy jest powolny jak w „powinien być poniżej 30 ms. Podczas gdy obecnie marnuje dziesięć sekund”, czy powolny jak „możemy skrócić czas trwania z dziesięciu do dziewięciu sekund”?

Na początku mojej kariery programisty pracowałem nad oprogramowaniem dla wielu moich klientów. Byłem przekonany, że to oprogramowanie jest kolejną wielką rzeczą, która przyniesie światu szczęście, więc najwyraźniej martwiłem się wydajnością.

Słyszałem terminy takie jak „profilowanie” lub „test porównawczy”, ale nie wiedziałem, co one oznaczają i nie obchodziło mnie to mniej. Co więcej, byłem zbyt skoncentrowany na czytaniu książki o C, a zwłaszcza rozdziale, w którym omawiano techniki optymalizacji. Kiedy odkryłem, że komputery wykonują mnożenie szybciej niż dzielenie, zamieniłem dzielenie na mnożenie gdziekolwiek mogłem. Kiedy odkryłem, że wywoływanie metody może być powolne, połączyłem tyle metod, ile mogłem, tak jakby poprzednie 100 metod LOC nie stanowiło już problemu.

Czasami spędzałem noce, wprowadzając zmiany, które - jak byłem przekonany - czyniły różnicę między wolną aplikacją, której nikt nie chce, a szybką, którą wszyscy chcą pobrać i używać. Fakt, że dwóch rzeczywistych klientów zainteresowanych tą aplikacją poprosiło o rzeczywiste funkcje, nie przeszkadzało mi: „Kto chciałby funkcji, jeśli aplikacja jest wolna?” - pomyślałem.

Wreszcie, tylko dwaj klienci przestali korzystać z aplikacji. Mimo moich wysiłków nie było to zadziwiająco szybkie, głównie dlatego, że gdy nie wiesz, jakie są indeksy, a Twoja aplikacja wymaga dużej bazy danych, coś jest nie tak. W każdym razie, kiedy robiłem tylko kolejną zmianę związaną z wydajnością, która poprawiała o kilka mikrosekund wykonanie kodu używanego raz w miesiącu, klienci nie widzieli zmian. Zauważyli, że doświadczenie użytkownika jest okropne, brakuje dokumentacji, kluczowych funkcji, o które prosili od miesięcy, nie było tutaj, a liczba błędów do rozwiązania stale rosła.

Wynik: mam nadzieję, że ta aplikacja będzie używana przez tysiące firm na całym świecie, ale dziś nie znajdziesz żadnych informacji na temat tej aplikacji w Internecie. Jedyni dwaj klienci zrezygnowali z tego i projekt również został porzucony. Nigdy nie był sprzedawany, nigdy nie reklamowany publicznie, a dziś nawet nie jestem pewien, czy uda mi się go skompilować na moim komputerze (ani znaleźć oryginalnych źródeł). Nie zdarzyłoby się to, gdybym bardziej skupiał się na rzeczach, które naprawdę mają znaczenie.

To powiedziawszy, ogólna wydajność jest ważna :

  • W aplikacjach innych niż biznesowe może to mieć kluczowe znaczenie. Istnieje oprogramowanie wbudowane , oprogramowanie działało na serwerach (gdy masz kilka tysięcy żądań na sekundę, co nie jest tak duże, wydajność zaczyna budzić obawy), oprogramowanie działało na smartfonach , grach wideo , oprogramowaniu dla profesjonalistów (spróbuj poradzić sobie 50 GB pliku w Photoshopie na niezbyt szybkiej maszynie do przekonania), a nawet zwykłe oprogramowanie sprzedawane wielu osobom (jeśli Microsoft Word poświęci dwa razy tyle razy na wykonanie każdej operacji, ile stracił, pomnożony przez liczbę użytkowników stanie się problemem).

  • W aplikacjach biznesowych, istnieje wiele przypadków, w których aplikacja, która czuje i jest powolny będą znienawidzeni przez użytkowników. Nie chcesz tego, spełniając swoje obawy.


4
Świetna odpowiedź, szczególnie dlatego, że skupiono się na bezsensownych dyskusjach dotyczących wyników i bezsensownych optymalizacji.
Doc Brown

1
a simple animated transition may often be the difference between an app which feels terribly slow and the app which feels responsive- chociaż z pewnością należy ich używać oszczędnie, to aplikacje, które wszędzie zaśmiecają animacje i przejścia, mogą być frustrujące, jeśli codziennie patrzymy na te przejścia!
Kosmiczny Ossifrage

jakie jest źródło twojej wyceny?
Adam Johns

1
@AdamJohns: brak źródła. Jest cytowany z szkiców moich artykułów, które nie zostały jeszcze opublikowane na moim blogu.
Arseni Mourzenko

@MainMa Oh super. Naprawdę podobała mi się ta mała ilustracja twojego punktu widzenia.
Adam Johns

44

Tak. Tak. Szybkość działania nie jest jedyną troską, którą powinieneś mieć, i nie jest tak nagląca, jak w 1982 r., Lub tak jak w przypadku systemów wbudowanych o niskiej mocy, ale zawsze jest to troska i ważne jest, aby zrozumieć dlaczego tak jest.

Po pierwsze, wspomniana asymptotyczna złożoność opisuje zachowanie programu wraz ze wzrostem jego wielkości wejściowej . Nieliniowy program, który zajmuje się 10 przedmiotami, może uciec od wykonywania zbędnej pracy, ale ugryzie cię, gdy pewnego dnia będziesz musiał poradzić sobie z 1000, ponieważ nie będzie to wydawać się wolniejsze, ale znacznie, dużo wolniejsze. I nie wiesz (bez obszernej analizy i analizy porównawczej), czy ten punkt będzie wynosił 100 przedmiotów, 1000 przedmiotów, czy nie, dopóki nie osiągniesz 100 000 przedmiotów. Trudno w to uwierzyć, ale wybór najlepszego algorytmu jest w rzeczywistości o wiele łatwiejszy niż oszacowanie tego punktu dla każdej procedury i wybranie implementacji w zależności od tego oszacowania.

Przeczytaj także podstawowe informacje o korzystaniu z interfejsu użytkownika. Istnieją dobrze zbadane progi, które określają sposób postrzegania interakcji z programem w zależności od czasu jego reakcji (10 ms, 100 ms, kilka sekund itp.). Przekroczenie jednego z tych progów spowoduje, że użytkownicy odejdą od Twojej aplikacji i jeśli nie jesteś w stanie pisać monopolu na oprogramowanie, z którego ludzie muszą korzystać, odłączeni użytkownicy przekładają się bezpośrednio na ujemną wartość biznesową, ponieważ prowadzi to do utraty klientów.

To tylko kilka powodów, dla których profesjonalny programista musi wiedzieć o złożoności algorytmicznej i obsługiwać ją w sposób odpowiedzialny. W dzisiejszych czasach zwykle nie trzeba zejść z drogi i zaprogramować specjalnie zoptymalizowany, źle czytelny kod do czegokolwiek, chyba że okazał się on krytyczną czasowo pętlą wewnętrzną, ale nigdy nie powinieneś nigdy wywoływać klasy złożoności wyższej niż jest to oczywiście konieczne wykonać pracę.


2
Jeszcze jedna rzecz, o której należy pamiętać przy wyborze algorytmu: ze względu na biblioteki i abstrakcje dokonano już wielu wyborów algo dla Ciebie lub przynajmniej „pod maską”. Nadal powinieneś znać ich wpływ na wydajność. A wydajność ma znaczenie .
joshin4colours

14

Tak!

Ponieważ pytałeś o przykłady, przychodzi na myśl kilka codziennych sytuacji:

  1. Obsługa dużych zbiorów danych : Wiele aplikacji biznesowych jest wspieranych przez bazy danych, aw wielu przypadkach bazy danych są przepełnione danymi. A ponieważ miejsce na dysku jest tanie, ilości nagranych i przechowywanych danych są szalone. W zeszłym tygodniu klient skarżył się, że jego aplikacja jest bardzo powolna, gdy wyświetla tylko niektóre średnie liczby (zapytania ponad kilka milionów wierszy ...) - Również w codziennym użyciu mamy konwersje danych obliczeniowych i obliczenia z czasami wykonania w lidze kilku godziny. W ubiegłym roku optymalizacja algorytmiczna skróciła czas przetwarzania jednej partii z 8 do 4 godzin, teraz już nie koliduje z dzienną zmianą!

  2. Reakcja : Przeprowadzono badania użyteczności (jeśli będę miał czas, dodam linki do odpowiednich pytań na stronie ux.se ...), że zadowolenie użytkownika jest ściśle związane z reakcją. Różnica w czasie reakcji wynoszącym 200 ms w porównaniu do 400 ms może łatwo kosztować duży procent klientów, pozostawiając cię konkurentom.

  3. Systemy wbudowane : komputery nie działają szybciej, stają się wolniejsze i mniejsze ^ _ ^ Tworzenie aplikacji mobilnych ma ogromny wpływ na tworzenie aplikacji. Jasne, że możemy ominąć cykle pamięci i procesora, takie jak Jelly Beans, na nowoczesnych komputerach stacjonarnych, ale teraz twój szef prosi cię o wdrożenie algorytmu analizy snu na dziwacznym zegarku lub na karcie SIM ...


4

W praktyce dzisiaj wydajność ma znaczenie w typowym normalnym programie biznesowym?

Nie wiem, co to jest typowy normalny program biznesowy. Wiem, że użytkownicy zawsze kończą karmieniem naszych programów znacznie większą ilością danych, niż planowaliśmy (często po sprawdzeniu, jak duży by był i dodaniu marginesu bezpieczeństwa) i że w takim przypadku oczekują liniowego wzrostu w czasie wykonywania, zaakceptuj zachowanie log n i narzekaj, że aplikacja zawiesza się, gdy dzieje się coś innego. I zwykle uważają, że rozmiar wyniku jest większy niż rozmiar danych wejściowych, z wyjątkiem przypadków, gdy z ich POV wynika, że ​​wszystkie dane wejściowe muszą zostać przetworzone.

Tak więc, wydajność, przynajmniej na poziomie złożoności, ma znaczenie. Mikrooptymalizacja wewnątrz klasy złożoności nie ma tak naprawdę znaczenia, z wyjątkiem sytuacji, gdy jesteś wyraźnie gorszy od konkurencji (albo w testach porównawczych na niektórych rynkach, albo przez surową percepcję - zmieniając klasę w sposób „natychmiastowy”, „nie natychmiastowy, ale użytkownik nie robi tego” „przełącz się na coś innego”, „wystarczająco wolno, aby użytkownik przeszedł na coś innego, ryzykując przerwanie przepływu działań”, „wystarczająco wolno, aby użytkownik uruchomił zadanie, a następnie sprawdzał od czasu do czasu”, „wystarczająco wolno że użytkownik planuje uruchomić zadanie w porze lunchu, w nocy, w weekend ”.


4

W nowoczesnych aplikacjach biznesowych problemy z wydajnością nie wynikają z braku procesora lub pamięci. Są one jednak w postaci opóźnień w sieci, wydajności we / wy i abstrakcji ukrywających je wszystkie. Wszystko zależy od tego, jak dobry jest projekt i od doświadczenia programistów. Nawet prosta aplikacja CRUD może zatrzymać się, jeśli pobiera z DB jeden wiersz na raz, zamiast uruchamiać zapytanie (znane również jako problem N + 1).

Problem polega na tym, że posiadanie dobrego projektu i doświadczonych programistów jest drogie. Zirytowani użytkownicy są zwykle znacznie tańsi niż inwestowanie w rzeczywistą optymalizację wydajności. W niektórych przypadkach klienci będą wymagać wysokiej wydajności (np. Przeglądarki internetowe), ale te rzadko dotyczą zwykłych aplikacji biznesowych.


3

Pamiętaj, że w przypadku aplikacji serwerowych możesz mieć setki, tysiące, a nawet miliony użytkowników próbujących robić rzeczy w tym samym czasie. Niewielka oszczędność wydajności w takiej sytuacji może mieć duży wpływ na ilość sprzętu wymaganego do obsługi zgłoszeń serwisowych.


5
W rzeczywistości większość stałych czynników można lepiej rozwiązać, rzucając więcej sprzętu na problem, ponieważ więcej sprzętu jest zwykle tańsze niż więcej czasu na optymalizację. Problemem jest złe zachowanie asymptotyczne (skalowanie), ponieważ rzucanie większą ilością sprzętu niewiele w tym pomoże.
Jan Hudec

3
Optymalizujesz tylko raz, ale płacisz rachunek za prąd co miesiąc.
Jaydee,

2
@ JanHudec: Nie do końca rozumiem, jak można to powiedzieć z czystą miną, gdy sama witryna, na której aktualnie się znajdujesz (nasza droga Stack Exchange), obsługuje miesięcznie 560 odsłon na całym świecie na zaledwie 25 serwerach .
Mehrdad

2
@Mehrdad: I mogliby napisać go w C, a być może uruchomiliby go na 20 serwerach zamiast 25. Ale nie zrobili tego, ponieważ oszczędności nie przeważałyby nad wydłużonym czasem programowania. Wiele usług sieciowych jest zaimplementowanych w Pythonie i PHP, które są jednymi z najwolniejszych powszechnie używanych języków, ale nikt nie myśli o przepisywaniu ich w jakikolwiek sposób, ponieważ wydłużony czas programowania nie byłby opłacalny. Stałe czynniki są przez większość czasu rozwiązywane przez dodanie do tego więcej sprzętu. Skalowanie (asymptotyczne) problemy to kolejna kwestia.
Jan Hudec

3
... I szczerze mówiąc, baza danych, która wykonuje większość pomruków, została napisana i zoptymalizowana pod kątem szybkiego działania.
Blrfl

3

To na pewno bardzo ważne.

Głównym problemem nie jest nawet denerwowanie użytkownika, takie jak doświadczanie niepotrzebnych opóźnień, gdy elementy GUI są przerywane dwukrotnie lub trzykrotnie (co ma znaczenie w zintegrowanej grafice!) Lub po prostu dlatego, że program zajmuje tyle czasu, aby zrobić ... cokolwiek to jest robi (głównie nieciekawe rzeczy). Chociaż oczywiście jest to również problem.

Istnieją trzy ważne nieporozumienia:

  1. Większość typowych komputerów biznesowych nie jest „o wiele bardziej wydajna” . Typowym komputerem biznesowym nie jest 8-rdzeniowy i7 z kartą graficzną typu kick-ass i 16 GB pamięci RAM. Jest to notebook z mobilnym procesorem średniej klasy, zintegrowaną grafiką, 2 GB pamięci głównej (4 GB, jeśli masz szczęście), dyskiem 5400 RPM oraz wersją systemu Windows dla przedsiębiorstw z różnorodnym oprogramowaniem antywirusowym i oprogramowaniem do egzekwowania zasad działającym w tło. Lub, dla większości konsultantów, „komputer” to po prostu iPhone ...
  2. Większość „typowych użytkowników biznesowych” nie jest technikami, nie rozumie implikacji stworzenia arkusza kalkulacyjnego z 10-12 kartami odsyłaczy, 150 kolumn i 30 000 wierszy (liczby te nie są tak nierealne, jak można przypuszczać!), A oni też nie chcę wiedzieć. Po prostu to zrobią.
  3. Druga przegrana nie kosztuje, jest to rażąco błędne założenie.

Moja żona pracuje w górnej części takiego „typowego środowiska biznesowego”. Komputer, którego używa, kosztuje około 3,5 godziny swojego czasu pracy. Uruchomienie programu Microsoft Outlook zajmuje - w dobry dzień - około 3 minut, zanim będzie gotowy (6-8 minut w kwartale, gdy serwery są obciążone). Niektóre z tych 30-wierszowych arkuszy kalkulacyjnych zajmują 2-3 sekundy na aktualizację wartości, podczas której komputer jest „zamrożony” (nie wspominając o tym, ile czasu zajmuje Excelowi uruchomienie i otwarcie ich!). Jeszcze gorzej jest podczas udostępniania pulpitu. Nawet nie każ mi korzystać z SAP.
Z pewnością ma znaczenie to, czy sto tysięcy osób traci 20–25 minut dziennie, czekając na nic. To miliony zagubionychktóre możesz zamiast stracić, wypłacić jako dywidendy (lub zapłacić wyższe wynagrodzenie).
Oczywiście większość pracowników znajduje się na dolnym końcu skali wypłat, ale nawet na niższym końcu są pieniądze .


3

Rozumiem, dlaczego to miało znaczenie, dekady temu. Komputery działały znacznie wolniej i miały znacznie mniej pamięci, więc trzeba było dokładnie przemyśleć te rzeczy.

Nie doceniasz, jak szybko rośnie N ^ 2. Załóżmy, że mamy komputer, a nasz algorytm N ^ 2 zajmuje 10 sekund, gdy N = 10. Czas mija, mamy teraz nowy procesor, który jest 6 razy szybszy niż nasz oryginalny, więc nasze 10-sekundowe obliczenia są teraz krótsze niż dwie sekundy. O ile większy N może być i nadal mieści się w tym oryginalnym 10-sekundowym czasie pracy? Możemy teraz obsłużyć 24 przedmioty, czyli nieco ponad dwa razy więcej. O ile szybciej nasz system musiałby obsługiwać 10 razy więcej przedmiotów? Musiałoby to być 100 razy szybsze. Dane rosną dość szybko i więcej niż niszczą postępy sprzętu komputerowego dla algorytmów N ^ 2.


Kolejny przykład: jeśli przetwarzanie jednego elementu zajmuje 30 cykli procesora lub 10ns (co jest dość tanie), algorytm zajmie pełną sekundę, jeśli masz tylko 10000 elementów. 10000 elementów nie jest wiele w wielu kontekstach.
CodesInChaos

1

Nie uwierzyłbyś, ile programów biznesowych innych firm używamy w pracy, a wiele z nich jest po prostu absurdalnie powolnych w użyciu w porównaniu do moich osobistych standardów. Gdyby programy były czymś, z czego korzystam w domu, już dawno zastąpiłbym je innym.

W niektórych przypadkach różnica wpływa bezpośrednio na koszty, ponieważ niektóre programy bezpośrednio wpływają na liczbę zadań, które mogę wykonać w ciągu dnia, a tym samym obniżają moją produktywność i ilość przedmiotów podlegających rozliczeniu. Powiedziałbym więc, że bardzo ważne jest, aby programy biznesowe były przynajmniej wystarczająco wydajne, aby nie były ograniczeniem dochodów.

Przykładem jest zarządzanie incydentami, w których praca jest mierzona w 15-minutowych odstępach (serwis). Jeśli program jest wystarczająco wolny, aby przesunąć jeden bilet na więcej niż 15 minut (włączając w to faktyczną pracę), znacznie spowolni ten proces. Jedną z przyczyn może być powolny dostęp do bazy danych, który po prostu „czeka na chwilę” za każdym razem, gdy użytkownik wykona czynność (wypełnij szczegóły dotyczące rozdzielczości, zaktualizuj informacje o pracy lub podobne). Mogę sobie wyobrazić, że zdarzają się przypadki, w których powolne programy mogą nawet wpływać na bardziej krytyczne rzeczy, takie jak dane pacjenta w szpitalu dotyczące pilnych przypadków zatrucia - może alergie na lekarstwa lub podobne?


1

Wiele innych odpowiedzi dość dokładnie omawia ten temat, dlatego odkładam je na uzasadnienie i uzasadnienie. Zamiast tego chcę podać prawdziwy przykład pokazujący, jak wybór algorytmu może mieć realne implikacje.

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

W połączonym artykule opisano błąd w algorytmie obliczającym aktualizacje systemu Windows XP. Przez większość życia systemu Windows XP algorytm aktualizacji działał dobrze. Algorytm oblicza, czy łatka została zastąpiona nowszą, a zatem nie wymaga instalacji. Jednak pod koniec lista zastąpionych aktualizacji wydłużyła się bardzo długo *.

Algorytm aktualizacji był wykładniczy, a każda nowa aktualizacja obliczała dwa razy dłużej niż poprzednia ( ). Gdy listy weszły w zakres 40 aktualizacji (* długi ), sprawdzenie dostępności aktualizacji zajęło 15 minut przy pełnej wydajności. To skutecznie zablokowało wiele komputerów XP podczas aktualizacji. Co gorsza, gdy ktoś chce zainstalować aktualizacje, algorytm uruchomi się ponownie , co zajmie kolejne 15 minut. Ponieważ wiele komputerów ma ustawione automatyczne aktualizacje, może to zablokować maszyny na 15 minut przy każdym rozruchu i potencjalnie ponownie z określoną częstotliwością.O(n) = 2n

Firma Microsoft zastosowała zarówno krótkoterminowe ataki hakerskie (usuwanie elementów z listy aktualizacji), jak i długoterminowe poprawki, aby rozwiązać ten problem. Było to ważne, ponieważ najnowsze wersje systemu Windows również używały tego samego algorytmu i mogą pewnego dnia napotkać ten sam problem.

Tutaj widzimy, że wybór algorytmu miał realne implikacje. Nieprawidłowy algorytm, choć grzywna przez większą część okresu użytkowania produktu, może mieć negatywny wpływ na całą drogę.


0

Myślę, że interpretujesz liczbę zadawanych pytań dotyczących wydajności jako wskazówkę, że wymagania dotyczące wydajności dla aplikacji biznesowych są ważne, zamiast uznać, że poprawa wydajności jest trudna . Po prostu uruchomienie go można osiągnąć za pomocą technik brutalnej siły, prób i błędów lub kopiowania i wklejania przykładowego kodu.

Każdy może mieć szczęście i wprowadzać zmiany, dopóki coś nie zacznie działać szybciej, ale to rzadko działa. Z powodu braku doświadczenia programiści zobaczą pomoc z zewnątrz. W niektórych środowiskach poprawa wydajności jest unikalnym problemem, więc zadawanie konkretnego pytania w witrynie, takiej jak StackOverflow, może być jedyną opcją. Ponadto wielu konsultantów zarabia pieniądze, mogąc wkroczyć i rozwiązać tego rodzaju problemy.


-1

Zależy to w dużej mierze od tego, jak zdefiniujesz „dobrą wydajność”. Twoje algorytmy powinny zawsze wykorzystywać możliwie najlepszą złożoność. Nadużywaj luk, aby przyspieszyć średnią klatkę. Buforowanie i wstępne ładowanie / prekompilacja w miarę możliwości w programie interaktywnym.

Istnieje inna definicja „dobrej wydajności”: Optymalizacja stałych twojej klasy złożoności. To tutaj C ++ dostaje swój tytuł, gdzie ludzie zaczynają nazywać Javę wolno, gdzie 5% mniej czasu działania wydaje się być świętym Graalem. Korzystając z tej definicji masz rację. Sprzęt komputerowy komplikuje się z czasem, a kompilatory stają się coraz lepsze. W pewnym momencie nie możesz tak naprawdę zoptymalizować kodu niskiej jakości lepiej niż kompilator - więc po prostu pozwól mu się skoncentrować na algorytmach.

W tym momencie użycie Java / Haskell / C ++ staje się kolejną decyzją projektową. Korekcję liczb można wykonać za pomocą OpenCL na GPU. Interfejsy użytkownika wymagają algorytmów stałego czasu i są dobre. Dane wyjściowe i modułowość są ważniejsze niż wyrównanie klas w celu lepszego wykorzystania pamięci podręcznej o 20%. Wielowątkowość staje się ważna, ponieważ ludzie nie chcą szybkiej aplikacji, chcą responsywnej. Nie ma znaczenia, że ​​Twoja aplikacja jest stale o 10% wolniejsza niż mogłaby być. Nawet 50% jest w porządku (ale ludzie zaczynają wtedy zadawać pytania). Skoncentruj się na poprawności, szybkości reakcji i modułowości.

Uwielbiam programować w Haskell lub przynajmniej w formie funkcjonalnej (nawet w C ++). Możliwość łatwego pisania testów dla całego programu jest o wiele ważniejsza niż bycie trochę szybszym w zadaniach wsadowych.


-1

Całkiem proste: koszt

Mój poprzedni pracodawca miał system zarządzania nauczaniem, który był hostowany na fizycznych serwerach jako model SaaS. Sterta JVM została skonfigurowana na 2 GB dla starszych komputerów i 3 GB dla nowszych komputerów i uruchomiliśmy kilka instancji na maszynę. Można by pomyśleć, że to wystarczy.

Zanim zacząłem, był zespół ds. Wydajności odpowiedzialny za sprawienie, aby system był responsywny i skalowany. Okazało się, że były pewne fragmenty danych, które ciągle szukaliśmy w bazie danych. Była jedna tabela, do której nawet przyłączyliśmy się do większości zapytań w celu pobrania jednej kolumny. Te dane rzadko się zmieniały.

Problem w tym, że mieliśmy 2 GB do pracy. Oczywistym rozwiązaniem jest rozpoczęcie buforowania wszystkich często odczytywanych danych. Potem mieliśmy problemy z pamięcią, zaczynając tuż przed moim wejściem na pokład.

Były 2 szkoły myślenia na ten temat:

  1. Ogólnie pamięć i sprzęt są obecnie tanie. Po prostu kup więcej pamięci RAM, aby móc buforować więcej.
  2. Dlaczego system zarządzania uczeniem potrzebuje ponad 3 GB pamięci RAM? Wszystko, co robi, wysyła zapytania SQL, wysyła przekierowania w celu uruchomienia kursów i ocenia postępy uczniów poprzez kursy.

Drugi argument wygrał i spędziłem ponad rok na dostrajaniu zużycia pamięci.

Mój obecny pracodawca obsługuje również system zarządzania uczeniem się, ale obsługuje go nieco inaczej. Skalowalność jest tak niska, że ​​jedna instalacja (podzielona na 4 wirtualne serwery z równoważeniem obciążenia) może obsłużyć tylko 80 klientów. Niektórzy z naszych większych klientów otrzymują nawet własny zestaw serwerów. Większość problemów, które do tego prowadzą, to problemy z wydajnością, takie jak zapytania SQL, które blokują wszystkie cykle procesora, wycieki pamięci, nadmiarowy kod, który robi to samo wiele razy. Mamy nawet wbudowaną aplikację, której jedynym celem jest ponowne uruchomienie serwerów, gdy nie działają one słabo. Jest pracownik, który utrzymuje to narzędzie (wraz z innymi obowiązkami).

Zasubskrybowali pierwszą szkołę myślenia, o której wspomniałem powyżej: rzuć na nią więcej sprzętu, ponieważ koszty sprzętu są tańsze niż wynagrodzenie programistów.

Nie zadziałało to tak ekonomicznie, jak oczekiwano. Między sprzętem, licencjonowaniem oprogramowania i personelem pomocniczym do obsługi serwerów, wydawaliśmy miliony rocznie, aby uniknąć sytuacji, w której deweloper spędza czas na profilowaniu kodu.

Kiedy dołączyłem, byłem odpowiedzialny za naprawienie naszych problemów z dostępnością. Ponieważ większość naszych problemów z dostępnością była spowodowana niską wydajnością, dostrajałem wydajność naszego kodu, a skalowalność uległa znacznej poprawie, a czas pracy był znacznie krótszy. Jesteśmy gotowi, aby zacząć zwiększać gęstość. Nie trzeba dodawać, że moja pensja nie zbliża się do miliona (chciałbym!), Więc wydawanie pieniędzy na dostosowanie wydajności kodu pozwoli nam zaoszczędzić miliony rocznie.

TL; DR

Jeśli przeprowadzisz dokładną analizę kosztów i korzyści, zobaczysz, że taniej jest po prostu naprawić kod. Znany problem z wydajnością, który ignorujesz, zamienia się w dług techniczny .


1
Nie każda analiza kosztów / korzyści spowoduje „naprawienie kodu”. Programiści są bardzo kosztowni i jeśli możesz dodać pamięć RAM za mniej niż koszt programisty i nadal rozwiązać problem ...
Robert Harvey

Fajnie, że przy tak dużej ilości przechodzenia do sytuacji hostingu w chmurze możesz zobaczyć, ile faktycznie płacisz za moc. Na przykład używamy Amazon RDS jako bazy danych. Różnica między największym i drugim co do wielkości wystąpieniem wynosi około. 3500 USD rocznie. Jest to liczba, na którą możesz spojrzeć i ocenić, czy warto poświęcić dużo czasu programistom na optymalizację.
Carson63000,

@RobertHarvey To prawda, nie powinienem był robić z tego absolutów. Chciałem powiedzieć, że absolutny „sprzęt jest tańszy niż czas tworzenia” nie jest absolutnie prawdą, ale masz rację, czasem może być prawdą.
Brandon,

-2

Zrozumiałem twoje pytanie w ten sposób: aby osiągnąć wystarczającą wydajność (tj. Użytkownicy są zadowoleni, a mój backend nie żałuje), czy muszę zrozumieć teorię złożoności algorytmu?

Zależy to od tego, co rozumiesz przez „typową” aplikację biznesową. W wielu przypadkach, szczególnie w prostych systemach informatycznych podobnych do CRUD, odpowiedź brzmiałaby „nie”. W przypadku tych „po prostu” (czasem jest to naprawdę trudne) musisz być w stanie prześledzić wąskie gardła wydajności: czy przegapiłem indeks w mojej bazie danych? Czy przesyłam za dużo danych przez sieć? Czy w interfejsie angular.js mam zegarek za tysiąc dolarów? Chodzi o zbudowanie solidnej architektury, znajomość stosu technologii i unikanie bezsensowności. Możesz to osiągnąć, jeśli jesteś dobrym rzemieślnikiem, niekoniecznie informatykiem. Innym sposobem na powiedzenie jest to, że faceci, którzy zbudowali optymalizator zapytań Oracle, zajmowali się zagadnieniami złożoności algorytmicznej, wystarczy właściwie użyć tego, co ci zapewnili.

Teraz są wyjątki. Jeśli mówimy o big data lub uczeniu maszynowym, musisz wiedzieć, co robisz, a nie tylko korzystać z domyślnych dostępnych algorytmów. Nawet w interfejsie, jeśli zaczniesz budować zaawansowane wizualizacje danych, niektóre z nich mogą oznaczać nieliniowy koszt złożoności (np. Wykresy układu siły).

W dzisiejszych czasach wyjątki te stają się coraz bardziej powszechne, a rynek jest dość suchy, gdy szukasz ludzi, którzy mogą je obsłużyć. Więc: tak, możesz odnieść sukces bez wiedzy informatycznej, ale z niektórymi będziesz jeszcze bardziej.


-2

Inni respondenci omówili większość podstawowych punktów, ale w przypadku zadań, które można zrównoleglać, nieefektywne oprogramowanie prowadzi do wzrostu kosztów sprzętu w postaci większej liczby serwerów, które zużywają więcej energii i wymagają więcej miejsca i konserwacji.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.