Dlaczego moje optymalizacje nie optymalizują?

Oryginalny post: Why Aren't My Optimizations Optimizing?

Autor: Jeff Atwood

"W 97% przypadków nie powinniśmy przejmować się wydajnością: przedwczesna optymalizacja jest źródłem wszelkiego zła." - Donald Knuth

Na blogu Michaela Tepera znajduje się doskonały wpis o autentycznym scenariuszu optymalizacji, związanej z podmianą stringów. Po zaimplementowaniu trzech logicznych alternatyw, Mike spojrzał na wyniki testów wydajności i zapytał,

Dlaczego moje optymalizacje nie optymalizują?

Optymalizacja kodu to śliski interes. Wypróbowałbym te same rzeczy -- prawdopodobnie w tej samej kolejności. Wielokrotnie, podejścia, o których zakładałem, że będą "szybsze", okazywały się błędne. To dlatego mówię programistom, zawsze mierzcie wydajność. Nigdy nie zakładajcie, że coś będzie szybsze czy wolniejsze, dopóki tego nie zmierzycie - będziecie zaskoczeni tym, jak często Wasze założenia są błędne. Niestety, czasami sposób w jaki mierzycie wydajność może być wadliwy. To jest to, co ujawniło, iż trzecia optymalizacja Mike'a była w rzeczywistosci optymalizacją:

okazało się, że Replace jest szybki jedynie wtedy, gdy wejściowy łańcuch znaków nie zawiera łańcucha (bądź znaku), który jest przeznaczony do podmiany. Natomiast, kiedy go zawiera, wydajność klasy CleanString spada oraz, tak jak oczekiwano, tablica znaków okazuje się bardziej wydajna.

Jeśli już musisz optymalizować, upewnij się, że testujesz poprawne przypadki z rozsądnym zbiorem danych testowych, aby upewnić się, iż faktycznie masz do czynienia z poprawą. A przed "ulepszaniem" czegokolwiek, zapamiętaj zasady optymalizacji M.A. Jacksona:

Zasady optymalizacji:

Zasada 1: Nie rób tego
Zasada 2 (tylko dla ekspertów): Jeszcze tego nie rób

I dodałbym trzecią: nie optymalizuj tego, czego nie trzeba. Nie zrozum mnie źle, wydajność jest niesamowicie ważna...

Podstawowa rada dotycząca czasu odpowiedzi nie zmieniła się przez prawie 30 lat [Miller 1968; Card et al. 1991]:

  • 0.1 sekundy to czas, który sprawia, iż użytkownik ma wrażenie, że system reaguje natychmiastowo, to znaczy, że żadna informacja zwrotna, oprócz wyniku, nie jest wymagana.
  • 1 sekunda to czas, który nie powoduje u użytkownika przerwania ciągu myślowego, nawet jeśli zaobserwuje on opóźnienie. Zazwyczaj żadna specjalna informacja nie jest potrzebna podczas opóźnień dłuższych niż 0.1, a krótszych niż 1 sekunda, ale użytkownik traci już uczucie pracy bezpośrednio na danych.
  • 10 sekund to maksymalny czas w jakim można utrzymać skupienie uwagi użytkownika. Dla dłuższych opóżnień, użytkownik będzie chciał wykonywać inne operacje podczas, gdy czeka na wynik poprzedniej, zatem powinna być dostarczona pewna informacja wskazująca oczekiwany czas ukończenia operacji. Informacje zwrotne podczas opóźnień są szczególnie ważne, kiedy czas odpowiedzi może być zmienny, gdyż użytkownicy nie wiedzą, czego mogą oczekiwać.

... tak jak posiadanie funkcjonalnego, stabilnego systemu. To do Ciebie należy decyzja, jak to wyważyć. Dla tych, którzy chcą wiedzieć więcej, to ten temat został doskonale potraktowany w 9 rozdziale książki Programming Pearls. Dodatkowo, Microsoft Performance Blogger Rico jest ciekawą (i .NET-ową) lekturą.

Data publikacji oryginału: 24 sierpnia, 2004

6 komentarze:

Tomasz Kowalczyk pisze...

Dwa ostatnie "bloki" - ten z zasadami optymalizacji i czasem oczekiwania należy sobie wydrukować i powiesić nad monitorem. Kolejny genialny artykuł. ;]

Konrad Kubiec pisze...

Popieram w pełni komentarz Tomasza. Dodałby tylko, aby nie tylko powiesić, ale i wdrożyć :)

Anonimowy pisze...

Ale czy nie lepiej pisać używając podstaw optymalizacji(nie pisać bardzo nie optymalnie) ?

Tomasz Kowalczyk pisze...

Jak piszę to zwykle wprowadzam od razu optymalizacje takie jak np. operatory prefixowe, ale na optymalizacje struktury czekam aż produkt będzie w pełni funkcjonalny.

@Konrad: jak powiesisz i będziesz na to patrzył przez pół dnia to w końcu wdrożysz. ;]

vshader pisze...

@Anonimowy: pamiętaj że w czasie pisania nie zawsze wiadomo jak często będzie wykorzystywany dany kod (tj. czy w ogóle opłaca się go optymalizować). Może się potem okazać że namęczyłeś się na marne.

Do podanych regułek, dorzuciłbym jeszcze jedną, również bardzo znaną - mówiącą w jakiej kolejności należy tworzyć oprogramownie:

1. Make it work
2. Make it easy
3. Make it fast

Sądzę że w połączeniu z zasadami podanymi przez Atwooda stanowi doskonałe remedium na wiele programistycznych bolączek.

Konradzik pisze...

Może źle rozumiem ten artykuł, ale akurat tak się złożyło, że kończę nową wersję serwisu www, i w miarę pisania wprowadzałem bardzo dużo optymalizacji. Tak, jest przez to więcej kodu, i tak, nie dam sobie ręki uciąć czy niektóre z tych optymalizacji nie są nadmiarowe, ale nie mogę pozwolić, żeby po wejściu na produkcje serwis nie wytrzymał obciążenia czy działał dużo wolniej od wersji poprzedniej. Zresztą nawet gdyby to była mała i nowa strona, czasami człowiek wie z doświadczenia, że ta czy inna część kodu nie będzie wydajna i dodanie optymalizacji 'just feels right'.

Prześlij komentarz

Related Posts with Thumbnails