W sprawie wydajności wyjątków można znaleźć wiele opinii, często sprzecznych ze sobą. W dzisiejszym wpisie przedstawię kilka programików, mających na celu, wyjaśnienie jaki wpływ mają wyjątki oraz ich łapanie na wydajność aplikacji. Zacznijmy od przykładów a potem przejdziemy do analizy wyników. Kod z wyrzucaniem wyjątków:

internal class Program
{        
   private static void Main(string[] args)
   {
       const int n = 20000;

       Stopwatch stopwatch = Stopwatch.StartNew();

       for (int i = 0; i < n; i++)
       {
           try
           {
               GetValueWithException();
           }
           catch 
           {                    
           }
       }

       Console.WriteLine(stopwatch.ElapsedTicks);
   }
   private static object GetValueWithException()
   {
       throw new Exception();
   }
}

Wynik w trybie Debug to 900167.

Następnie analogiczna konstrukcja zwracająca po prostu NULL:

internal class Program
{        
   private static void Main(string[] args)
   {
       const int n = 20000;

       Stopwatch stopwatch = Stopwatch.StartNew();

       for (int i = 0; i < n; i++)
       {
        if (GetValueWithoutException() == null)
        {
            
        }
       }

       Console.WriteLine(stopwatch.ElapsedTicks);
   }
   private static object GetValueWithoutException()
   {
       return null;
   }
}

W trybie Debug uzyskano 760. Różnica jest więc kolosalna. Dlaczego wyrzucanie wyjątków jest tak wolne?

Najpierw musimy stworzyć nowy obiekt Exception, który jest klasą. Wiąże się  to z zadeklarowaniem pamięci na stercie. Następnie GC będzie musiał te wszystkie obiekty zebrać co jest ogromnym wyzwaniem i wpływa zdecydowanie niekorzystnie na wydajność.  W drugim rozwiązaniu zwracamy po prostu NULL czyli status operacji.

Należy zdać sobie sprawę, że wyjątki to coś więcej niż status wykonania operacji. Zaglądając do klasy Exception, znajdziemy tam wiele informacji o kontekście operacji, która nie powiodła się. Mamy do dyspozycji stacktrace, który zawiera informacje o tym, jakie metody były wykonane. Co za tym idzie, im większy stacktrace tym prawdopodobnie wyrzucenie wyjątku będzie trwało dłużej (więcej informacji do zebrania). Ponadto, wyjątek po drodze może zostać złapany i ponownie wyrzucony co jeszcze bardziej zwiększa czas wykonania. Tekst wyjątku, warto zauważyć jest zawsze w lokalnym języku – lokalizacja jest również drobnym obciążeniem. Istnieje możliwość zagnieżdżonych try-catch. Innymi słowy, wydajność wyjątków w dużej mierze zależy od głębokości stosu.

Inną ciekawą przyczyną dlaczego wyjątki są wolniejsze jest pamięć podręczna CPU. Wyrzucając wyjątek, zostanie ona zmieniona a co za tym idzie, w dalszej części algorytmu\programu będziemy mieli do czynienia z “cache misses’, co oznacza, że dane na których wcześniej operowaliśmy znów będą musiały zostać załadowane do cache.

Wyjątki jeszcze wolniejsze są w sytuacji, gdy wyrzucamy je pomiędzy AppDomain lub kodem zarządzanym\niezarządzanym – wtedy muszą być serializowane co dodatkowo obciąża CPU.

Wyjątki są traktowane w sposób specjalny przez CLR lub nawet Visual Studio. Każdy wyrzucony wyjątek jest od razu wyświetlany w oknie output. Oczywiście mowa tutaj o trybie Debug. Ponadto, mamy do dyspozycji wiele handlerów zarówno w AppDomain jak i w klasach typu Application (w zależności czy korzystamy z WPF czy WinForms).

Czy to znaczy, że mamy unikać wyjątków? NIE! Powyższy przykład jest tylko dowodem na to, że wyjątki nie służą do sterowania przepływem logiki. Oczywiście jest to zła praktyka i post udowadnia to z punktu wydajnościowego. Wyjątki powinny być używane gdy coś “wyjątkowego” zdarzyło się. Jeśli wyrzucamy kilka tysięcy wyjątków w ciągu godziny wtedy ma to niekorzystny wpływ na wydajność ale to znaczy , że architektura jest zła i wyjątki zostały użyte po prostu w niewłaściwy sposób.

Na koniec inny przykład:

internal class Program
{        
   private static void Main(string[] args)
   {
       const int n = 20000;

       Stopwatch stopwatch = Stopwatch.StartNew();

       for (int i = 0; i < n; i++)
       {
           try
           {
               GetValueWithException();
           }
           catch (Exception)
           {                    
           }
       }

       Console.WriteLine(stopwatch.ElapsedTicks);
   } 
   private static object GetValueWithException()
   {
       return null;
   }
}

Wynik to 700. Jeśli nie wyrzucamy wyjątków wtedy catch nie ma praktycznie żadnego obciążenia. “Problemy” zaczynają się wyłącznie wtedy, gdy korzystamy z throw a nie catch.

Często spotykam następujące konstrukcje:

class RiskInfo
{
    public int Condition{get;set;}
    public double Score{get;set;}
}

Innymi słowy, kontener na kilka prostych zmiennych. Jeśli ktoś nie zna zasady działania Garbage Collector, gorąco zachęcam do przeczytania np. mojego cyklu artykułów o GC. Usunięcie obiektu z pamięci to nie prosta sprawa i naprawdę wiele musi zostać wykonanych operacji w tle. Z tego względu, jeśli klasa jest mała i posiada wiele instancji, wtedy dużo lepiej skonwertować ją do struktury. Dużo łatwiej usunąć 100 instancji struktur ze stosu niż 100 instancji klas z zarządzanej sterty. Z mojego doświadczenia wynika, że programiści kojarzą struktury ale jakoś w praktyce z nich nie korzystają. Warto zastanowić się czy w projekcie nie mamy obiektów, spełniających powyższe kryteria.

Niestety bardzo często struktury są źle wykorzystywane.  Ktoś mógłby napisać następujący kod:

struct RiskInfo
{
    public int Condition{get;set;}
    public double Score{get;set;}
}

Niestety powyższy kod jest przykładem złej praktyki. Każda struktura musi być zawsze immutable (niezmienna). O ogólnych korzyściach wynikających z niezmienności obiektów pisałem już tutaj. W kontekście struktur jest to naprawdę ważne. Wyobraźmy sobie następujący kod:

internal class Program
{
   private static void Main(string[] args)
   {
       RiskInfo[] risks=new RiskInfo[2];
       RiskInfo riskInfo = risks[0];
       riskInfo.Condition = 10;

       Console.WriteLine(risks[0].Condition);
   }  
}

Nie jest wymagane od programisty, aby wiedział jak wewnętrznie został zaimplementowany RiskInfo. Stąd powyższy kod ma jak najbardziej sens. Problem w tym, że na ekranie wyświetli się 0 a nie 10. Bez wiedzy o tym, że RiskInfo to struktura łatwo popełnić błąd. Podobnie z właściwościami:

internal class Program
{
   private static void Main(string[] args)
   {
       RiskInfo.Condition = 10;
   }
   public static RiskInfo RiskInfo { get; set; }
}

Na szczęście powyższy problem zostanie już wykryty na etapie kompilacji. Szczególnie niebezpieczny kod (znaleziony na blogu Eric Lippert’a) to:

internal class Program
{
   public static readonly RiskInfo RiskInfo=new RiskInfo();

   private static void Main(string[] args)
   {
       Console.WriteLine(RiskInfo.CalculateScore());
       Console.WriteLine(RiskInfo.CalculateScore());
       Console.WriteLine(RiskInfo.CalculateScore());
   }
}
struct RiskInfo
{
   public int Condition { get; set; }
   public double Score { get; set; }

   public double CalculateScore()
   {
       Score = Score + 1;
       return Score;
   }
}

Co na ekranie wyświetli się? Każdy spodziewa chyba się 1,2,3 ale jednak będzie to 1,1,1. Dlaczego? Spróbujmy to wyjaśnić.  Jeśli usunęlibyśmy readonly wtedy problem by nie istniał. Na ekranie byśmy zobaczyli oczekiwane 1,2,3. Aby to wyjaśnić musimy zajrzeć do specyfikacji c# tutaj. Znajdziemy tam następujący cytat:

“If E is a value, or if the field is readonly and the reference occurs outside an instance constructor of the struct in which the field is declared, then the result is a value, namely the value of the field I in the struct instance given by E. “

Innymi słowy, jeśli odwołujemy się do zmiennej spoza konstruktora, wtedy nie operujemy bezpośrednio na niej a na wartości. Czyli to tak samo, jakbyśmy mieli właściwość zwracającą RiskInfo – wykonana zostanie kopia za każdym razem. W powyższym przykładzie, operujemy na 3 różnych kopiach, ponieważ po za konstruktorem, readonly zachowuje się bardziej jak właściwość – nie operuje na zmiennej.  Przenieśmy logikę do konstruktora i zobaczymy na ekranie 1,2,3:

internal class Program
{
   public readonly RiskInfo RiskInfo=new RiskInfo();
   
   public Program()
   {
       Console.WriteLine(RiskInfo.CalculateScore());
       Console.WriteLine(RiskInfo.CalculateScore());
       Console.WriteLine(RiskInfo.CalculateScore());
   }

   private static void Main(string[] args)
   {            
       Program program=new Program();
   }
}

Takich kruczków jest naprawdę wiele. Z tego względu dużo lepiej zaimplementować RiskInfo w następujący sposób:

internal struct RiskInfo
{
   public readonly int Condition;
   public readonly double Score;

   public RiskInfo(int condition, double score) : this()
   {
       Condition = condition;
       Score = score;
   }
}

Załóżmy, że w kodzie zobaczymy enum’a np.:

public enum Colors
{
   Black,
   Red,
   Yellow
};

Jeśli budujemy framework lub jakąkolwiek bibliotekę należy być świadomym zagrożeń wynikających z wewnętrznej budowy enum’a. Warto zajrzeć do Reflector’a aby przekonać się o tym:

.class public auto ansi sealed Colors
    extends [mscorlib]System.Enum
{
    .field public static literal valuetype ConsoleApplication1.Colors Black = int32(0)

    .field public static literal valuetype ConsoleApplication1.Colors Red = int32(1)

    .field public specialname rtspecialname int32 value__

    .field public static literal valuetype ConsoleApplication1.Colors Yellow = int32(2)

}

Problemem są oczywiście stałe. Powyższy enum wygląda mniej więcej następująco:

public static class CustomColors
{
   public const int Black = 0;
   public const int Red = 1;
   public const int Yellow = 2;
}

Jeśli ktoś nie kojarzy problemów ze stałymi to zapraszam do mojego wpisu tutaj. W skrócie, stała jest wstrzykiwana na etapie kompilacji. Po kompilacji, miejsce gdzie odwołujemy się do stałej jest zastępowane konkretną wartością. Jeśli piszemy system modularny wtedy w końcu możliwe jest, że biblioteka ze stałymi zostanie zmodyfikowana. Niestety wszystkie zależne biblioteki nie będą odzwierciedlać tej zmiany bez ponownej kompilacji. Oczywiście jeśli stała jest faktycznie niezmienna (klasyczny przykład PI) wtedy nie ma z tym problemu. Dobrą praktyką jednak jest (jeśli nie ma się do tego pewności) użycie pól read-only zamiast const, jeśli musimy zadeklarować dane pole jako publiczne. Każdy element publiczny powinien być zaprojektowany w ten sposób, że nie wymaga rekompilacji – w końcu udostępniamy go innym programistom.

Jeśli powyższe ryzyka faktycznie są nie do zaakceptowania dla danego projektu, wtedy po prostu lepiej napisać:

public static class CustomColors
{
   public static readonly int Black = 0;
   public static readonly int Red = 1;
   public static readonly int Yellow = 2;
}

Zostanie to przetłumaczone na:

.class public abstract auto ansi sealed beforefieldinit CustomColors
    extends [mscorlib]System.Object
{
    .method private hidebysig specialname rtspecialname static void .cctor() cil managed
    {
    }


    .field public static initonly int32 Black

    .field public static initonly int32 Red

    .field public static initonly int32 Yellow

}

 

W ostatnim wpisie przedstawiłem aspekt do obsługi wyjątków. Dzisiaj trochę więcej o samych aspektach dla metod. Oprócz wyświetlenia  nazwy metody czy przekazanych parametrów można wyciągnąć trochę więcej informacji. Dla przypomnienia, parametry można wyświetlać następująco:

public override void OnEntry(MethodExecutionArgs args) 
{ 
    var argValues = new StringBuilder(); 
    
    foreach (var argument in args.Arguments) 
    { 
        argValues.Append(argument.ToString()).Append(","); 
    } 
 
    Console.WriteLine("The {0} method was entered with the parameter values: {1}", 
    args.Method.Name, argValues.ToString()); 
} 

Możliwe jest również czytanie lub modyfikowanie wartości zwracanej. Przykład:

public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnExit(MethodExecutionArgs args)
   {
       base.OnExit(args);
       Console.WriteLine("Orginalna wartosc:{0}",args.ReturnValue);
       args.ReturnValue = "Test";
   } 
}    

internal class Program
{
   private static void Main()
   {
       Console.WriteLine(GetText());
   }          
   [MyAspect]
   private static string GetText()
   {
       return "Witaj swiecie.";
   }
}

Właściwość ReturnValue jest do odczytu i zapisu więc można zmienić to co funkcja początkowo zwróciła.

Można również mieć dostęp do klasy, do której aspekt został doczepiony tzn.:

public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnEntry(MethodExecutionArgs args)
   {
       base.OnEntry(args);
       Console.WriteLine(args.Instance.ToString());
   }
}

internal class Wrapper
{
   [MyAspect]
   public string GetText()
   {
       return "Witaj swiecie.";
   }
}

internal class Program
{
   private static void Main()
   {
       Wrapper wrapper=new Wrapper();
       Console.WriteLine(wrapper.GetText());
   }                
}

W powyższym przykładzie, Instance zawiera referencję na obiekt klasy Wrapper.

Z kolei właściwość Method zawiera informację o metodzie w formie MethodBase:

public override void OnEntry(MethodExecutionArgs args)
{
    base.OnEntry(args);
    Console.WriteLine(args.Method.Name);
    Console.WriteLine(args.Method.IsVirtual);
}

Ciekawą właściwością jest FlowBehaviour. FlowBehaviour przyjmuje następujące wartości: Default, Continue, RethrowException, Return, ThrowException. Poniższy kod wyświetli tylko jedną wiadomość ponieważ w aspekcie ustawiamy FlowBehaviour na Return co spowoduje po prostu wykonanie return przed logiką metody:

[Serializable]
public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnEntry(MethodExecutionArgs args)
   {
       if ((bool)args.Arguments[0])
           args.FlowBehavior = FlowBehavior.Return;
   }
}
internal class Program
{
   private static void Main()
   {
       DoSomething(true);
       DoSomething(false);
   }
   [MyAspect]
   public static void DoSomething(bool flag)
   {
       Console.WriteLine("Witaj swiecie:{0}",flag);
   }
}

RethrowException z kolei jest przydatny, gdy przeciążamy OnException:

public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnException(MethodExecutionArgs args)
   {
       Console.WriteLine("Zlapano wyjatek");
       args.FlowBehavior = FlowBehavior.RethrowException;
   }
}
internal class Program
{
   private static void Main()
   {
       DoSomething(true);
       DoSomething(false);
   }
   [MyAspect]
   public static void DoSomething(bool flag)
   {
       throw new NotImplementedException();
   }
}

RethrowException jak sama nazwa mówi, wyrzuci ponownie ten sam wyjątek. Najpierw on zostanie złamany w celu wywołania OnException na aspekcie a potem przez RethrowException zostanie on ponownie wyrzucony.

Kolejną wartością jest ThrowException, który wyrzuci nowy wyjątek zdefiniowany w aspekcie:

[Serializable]
public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnException(MethodExecutionArgs args)
   {
       Console.WriteLine("Zlapano wyjatek");
       args.Exception=new Exception("Custom exception");
       args.FlowBehavior = FlowBehavior.ThrowException;
   }
}
internal class Program
{
   private static void Main()
   {
       DoSomething(true);
       DoSomething(false);
   }
   [MyAspect]
   public static void DoSomething(bool flag)
   {
       throw new NotImplementedException();
   }
}

Jeśli nie ustawilibyśmy właściwości Exception wtedy FlowBehaviour.ThrowException i FlowBehaviour.RethrowException miałby takie same znaczenie.

Z kolei Continue zdławi wyjątek i należy tego w większości sytuacjach unikać jeśli chodzi o metodę OnException:

[Serializable]
public class MyAspect : OnMethodBoundaryAspect
{
   public override void OnException(MethodExecutionArgs args)
   {
       Console.WriteLine("Zlapano wyjatek");
       args.FlowBehavior = FlowBehavior.Continue;
   }
}

Domyślną wartością jest FlowBehaviour.Default co oznacza, że dla OnException będzie to RethrowException a dla OnExit\OnEntry Continue.

Ostatnią właściwością jaką chciałem omówić jest MethodExceuctionTag. Jeśli zachodzi potrzeba dzielenia stanu pomiędzy poradami (OnEntry, OnExit)  możemy właśnie z tego skorzystać. Na przykład aspekt sprawdzający jak długo metoda była wykonywana można zaimplementować następująco:

[Serializable]
public class PerformanceAspect : OnMethodBoundaryAspect
{
   public override void OnEntry(MethodExecutionArgs args)
   {
       args.MethodExecutionTag = Stopwatch.StartNew();
   }

   public override void OnExit(MethodExecutionArgs args)
   {
       var sw = (Stopwatch)args.MethodExecutionTag;
       sw.Stop();

       Console.WriteLine("{0}:{1}", args.Method.Name,sw.ElapsedMilliseconds);
   }
} 

Wyłącznie w powyższy sposób należy przekazywać dane pomiędzy zdarzeniami – nie można polegać na prywatnych polach jak to byśmy zrobili w klasycznej klasie!

O programowaniu aspektowym kiedyś już pisałem więc jeśli od strony teoretycznej nie jest to jasne to zachęcam do poszperania na blogu. Dzisiaj zaprezentuje framework Postsharp w wersji express (darmowa edycja, również do zastosowań komercyjnych). Jak wiemy, obsługa wątków czy wykonanie logów mogą być problemami cross-cutting. Postsharp jest typowym framework’iem implementującym AoP Zaczynamy od instalacji z NuGet:

Pomimo, że Postsharp express jest w pełni darmowy, musimy zarejestrować się i uzyskać klucz:

Następnie możemy zdefiniować nasz pierwszy aspekt, który uruchomi się w momencie wyrzucenia wątku. Generalnie w Postsharp istnieje kilka klas bazowych dla aspektów. W naszym przypadku skorzystamy z OnMethodBoundaryAspect, która zawiera kilka ciekawych metod. Implementacja aspektu polega po prostu na dziedziczeniu z OnMethodBoundaryAspect i przeładowaniu kilku metod. Zaglądając do dokumentacji dowiemy się trochę więcej o OnMethodBoundaryAspect:

[SerializableAttribute]
public abstract class OnMethodBoundaryAspect : MethodLevelAspect, 
    IOnMethodBoundaryAspect, IMethodLevelAspect, IAspect

Aby zobaczyć jakie metody możemy przeładować i kiedy są one wywołane przyjrzyjmy się następującemu pseudo-kodowi:

int MyMethod(object arg0, int arg1)
{
  OnEntry();
  try
  {
    // Original method body. 
    OnSuccess();
    return returnValue;
  }
  catch ( Exception e )
  {
    OnException();
  }
  finally
  {
    OnExit();
  }
}

Innymi słowy, mając metodę MyMethod, OnEntry zostanie wywołane przy wejściu do niej, OnSucces po wykonaniu logiki w niej zawartej, OnException w przypadku wyjątku, a OnExit zawsze przy wyjściu (niezależnie czy był wyjątek czy nie).

W naszym przypadku będziemy potrzebować tylko OnException. Zaimplementujmy więc pierwszy aspekt (zmodyfikowany przykład z oficjalnej dokumentacji Postsharp):

[Serializable]
public class ExceptionAspect : OnMethodBoundaryAspect
{
   private string methodName;
   
   public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
   {
       Debug.Assert(method.DeclaringType != null, "method.DeclaringType != null");
       methodName = method.DeclaringType.FullName + "." + method.Name;
   }
   public override void OnException(MethodExecutionArgs args)
   {
       Trace.Unindent();

       StringBuilder stringBuilder = new StringBuilder(1024);

       // Write the exit message. 
       stringBuilder.Append("Error:");
       stringBuilder.Append(this.methodName);
       stringBuilder.Append('(');

       // Write the current instance object, unless the method 
       // is static. 
       object instance = args.Instance;
       if (instance != null)
       {
           stringBuilder.Append("this=");
           stringBuilder.Append(instance);
           if (args.Arguments.Count > 0)
               stringBuilder.Append("; ");
       }

       // Write the list of all arguments. 
       for (int i = 0; i < args.Arguments.Count; i++)
       {
           if (i > 0)
               stringBuilder.Append(", ");
           stringBuilder.Append(args.Arguments.GetArgument(i) ?? "null");
       }

       // Write the exception message. 
       stringBuilder.AppendFormat("): Exception ");
       stringBuilder.Append(args.Exception.GetType().Name);
       stringBuilder.Append(": ");
       stringBuilder.Append(args.Exception.Message);

       // Finally emit the error. 
       Console.WriteLine(stringBuilder.ToString());
   }
} 

Metoda CompileTimeInitialzie jest wykonywana zawsze gdy aspekt jest doczepiony do konkretnej metody. Następnie w OnException pobieramy przydatne informacje takie jak nazwa metody, lista przekazanych parametrów czy stacktrace. Myślę, że możliwość wyprintowania parametrów i ich wartości jest niesłychanie przydatna. Oprócz tego, że będziemy wiedzieć gdzie wyjątek został wyrzucony, aspekt dostarczy nam informacji o konkretnym scenariuszu.

To nie koniec. Musimy zdefiniować zasady aplikowania aspektu. Najpierw spróbujmy doczepić aspekt do konkretnej, pojedynczej metody np.:

internal class Program
{
   private static void Main()
   {
       MethodCausingError("Witaj swiecie.");
   }   
   [ExceptionAspect]
   private static void MethodCausingError(string text)
   {
       throw new ArgumentException("Jakis blad.");
   }
}

Na ekranie, zobaczymy przechwycony wyjątek, wraz z parametrami:

W praktyce jednak, dużo lepiej skorzystać z bardziej globalnego mechanizmu tzn.:

[assembly: ExceptionAspect(AttributeTargetTypes = "*")] 

Powyższa linijka kodu zaaplikuje aspekt na każdej metodzie. Można również określić filtr, np. poprzez zdefiniowanie namespace:

[assembly: OurLoggingAspect(AttributeTargetTypes= 
"OurCompany.OurApplication.Controllers.*")] 

jeśli jest to nie wystarczające to można określić również widoczność typu (private, public itp.) czy typ metody:

[assembly: OurLoggingAspect 
(AttributeTargetTypes="OurCompany.OurApplication.Controllers.*",  
AttributeTargetTypeAttributes = MulticastAttributes.Public)]
// II
[assembly: OurLoggingAspect 
(AttributeTargetTypes="OurCompany.OurApplication.Controllers.*",  
AttributeTargetMemberAttributes = MulticastAttributes.Virtual)] 

W zasadzie warto na koniec zaznaczyć, że dla tego przykładu lepiej byłoby skorzystać z OnExceptionAspect zamiast OnMethodBoundaryAspect ponieważ wystarczy np. wyłącznie metoda OnException. To tylko takie wprowadzenie, w następnych wpisach pokażę bardziej szczegółowo sterowanie przepływem metod.