niedziela, 6 października 2013

Zapraszam do czegoś w stylu fotoreportażu z przeprowadzonych testów, który znajduje się TUTAJ...

StringBuilder wolniejszy od System.String.Concat?


POBIERZ PRZYKŁAD...

2 komentarze :

  1. Rys:26. "Modyfikuję pierwszą metodę pod tym kontem, przyprowadzając ją do stanu wyjściowego." - "pod tym kątem" jeśli już, a po drugie jeśli faktycznie chciałbyś wrócić do stanu wyjściowego, powinieneś użyć operatora '=' zamiast '+='...
    Rys:28. "JESTEŚMY PO RAZ KOLEJNY URATOWANI." - w związku z powyższym błędem raczej nie bardzo jesteśmy uratowani ;P Dla 100000 string'ów czas uzyskany dla metody faktycznie przywróconej do stanu wyjściowego jest o połowę krótszy niż ten, który Ty uzyskałeś. Wobec tego wygląda na to, że użycie konkatenacji nadal jest w tym przypadku sporo wydajniejsze, niż wykorzystanie StringBuilder'a... Owszem, dopisując kolejne zera do liczby przetwarzanych string'ów uzyskamy wreszcie sytuację, dla której proporcje się odwrócą, niemniej jednak pozostaje pytanie jak często przychodzi nam operować jednocześnie na milionach string'ów :).
    Rys:28. "Pierwszy: prędkość wykonania pierwszej metody StringConcat znacznie wzrosła." - chciałeś chyba napisać, że znacznie zmalała?

    OdpowiedzUsuń
  2. Rys:26. Fakt - tam zamiast '+=' powinien znaleźć się operator '='.

    Rys:28. W związku z poprawą powyższego błędu ponownie wykonałem testy wydajności. Zachowałem taką samą ilość iteracji, jak w przypadku testu którego wyniki znajdują się na slajdzie trzydziestym.

    Przy liczbie iteracji 10 000 000 wyniki przedstawiają się następująco:
    Czas wykonywania System.String.Concat: 5421 milisekund.
    Czas wykonywania StringBuilding1: 4000 milisekund.
    Czas wykonywania StringBuilding2: 4923 milisekund.

    Jak słusznie zauważyłeś, wskazany przez Ciebie błąd wpłynął na zmniejszenie czasu wykonania obliczeń w metodzie StringConcating. Jednak obliczenia te nadal są sporo wolniejsze od tych zaimplementowanych w metodzie StringBuilding1. W wyniku poprawy błędu zmienił się jedynie rozmiar porażki. Wcześniej czas wykonania metody przy użyciu String.Concat wynosił około 6.5 sekundy, obecnie wynosi około 5.5 sekundy, podczas gdy czas obliczeń przy użyciu StringBuildera wacha się w okolicach 4 sekund. „NADAL JESTEŚMY URATOWANI”.

    Słusznie zauważyłeś, że gdy będziemy zmniejszać ilość iteracji, czasy wykonań będą się zmieniać na niekorzyść StringBuilder’a. Wykonałem kilka testów, z których wyniki zamieszczam poniżej. Jeśli ktoś zna jaki jest powód odwrócenia opłacalności przy mniejszych tablicach to proszę o komentarz. Aspekt jak często w codziennej pracy operujemy na tak dużych tablicach w tym poście pomijam. Bardziej ciekawi mnie dlaczego przy mniejszych rozmiarach tablic String.Concat staje się szybszy.

    W poście (adres poniżej) zamieściłem inny przykład programu, w którym testuję wydajność obiektu StringBuilder w porównaniu z String.Concat.

    http://teo-vincent.blogspot.com/2013/11/sytuacja-gdy-stringbuilder-jest-duzo.html

    Wyniki:
    Ilość iteracji/rozmiar tablicy: 10 000 000
    Czas wykonywania System.String.Concat: 5421 milisekund.
    Czas wykonywania StringBuilding1: 4000 milisekund.
    Czas wykonywania StringBuilding2: 4923 milisekund.

    Ilość iteracji/rozmiar tablicy: 1 000 000
    Czas wykonywania System.String.Concat: 608 milisekund.
    Czas wykonywania StringBuilding1: 409 milisekund.
    Czas wykonywania StringBuilding2: 503 milisekund.

    Ilość iteracji/rozmiar tablicy: 100 000
    Czas wykonywania System.String.Concat: 46 milisekund.
    Czas wykonywania StringBuilding1: 50 milisekund.
    Czas wykonywania StringBuilding2: 88 milisekund.

    Ilość iteracji/rozmiar tablicy: 10 000
    Czas wykonywania System.String.Concat: 2 milisekund.
    Czas wykonywania StringBuilding1: 6 milisekund.
    Czas wykonywania StringBuilding2: 4 milisekund.

    Rys:28. Chciałem napisać: „{…} prędkość wykonania pierwszej metody StringConcat znacznie wzrosła.”, co jest jednoznaczne ze zdaniem: „{…} czas wykonania pierwszej metody znacznie zmalał.”.

    Dzięki za trafne uwagi.

    OdpowiedzUsuń