Lazy Loading mit IoC

Update vom 04.09.2013: Beachtet bitte die Kommentare. Das Lazy-Feature kann auch erhebliche Performance-Einbußen zur Folge haben. Es kommt darauf, was der Konstruktur des Lazy-Objekts noch an Abhängigkeiten hat und welche Logik in selbigem noch ausgeführt wird.

In diesem Webcast zeige ich welche Möglichkeiten Castle.Windsor für das Lazy Loading von Abhängigkeiten bietet. Das Feature wurde in Version 3 eingeführt. Weiterführenden Inhalt welche Performance Gedanken dahinter stecken und wann idealerweise der Graph des Container geladen werden sollte, findet ihr hier und hier.

Für diejenigen, die einen anderen Container nutzen: Falls euer Framework die Funktionalität nicht out-of-the-box mitliefert, so stellt sich eine eigene Lösung nicht als allzu schwierig heraus. In dem oben zuletzt erwähnten Link gibt es dazu ein Code Sample.

Als grobe Richtlinie kann man sich merken:

Das Laden von weiteren Abhängigkeiten wird v.a. dann “teuer”, wenn die Implementierungen in Assemblies liegen, die noch nicht geladen wurden.

Mit Tag(s) versehen: ,

5 thoughts on “Lazy Loading mit IoC

  1. oliverguhr 2. September 2013 um 14:43 Reply

    Die Zeit die du gemessen hast, dürfte zum größten Teil auf das Console.WriteLine zurückzuführen sein. Das reine erstellen der Objekte sollte wesentlich schneller ablaufen. Spannend wäre ob sich die Performance auch um 1/3 verbessert wenn man das Beispiel ohne Console.WriteLine laufen lässt.

    Gefällt mir

  2. Uli Armbruster 4. September 2013 um 10:45 Reply

    Sehr guter Hinweis. In der Tat ist die Lazy-Implementierung, wenn im Konstruktor nichts weiter ausgeführt wird, sogar erheblich langsamer! Bei einer Million Objekt waren es nach meiner Messung 40 Sekunden, wohingegen beim Verzicht auf das Lazy-Feature nur 17 Sekunden gebraucht wurden.

    Gefällt mir

  3. Uli Armbruster 4. September 2013 um 11:00 Reply

    Ich habe gerade einmal eine neue Rechnung laufen lassen. Dabei hat Impl2 noch eine Abhängigkeit zu ITest4 und die Implementierung Impl4 noch eine Abhängigkeit zu ITest5. Das ganze habe ich für 100.000 Objekterstellungen von Impl1 laufen lassen. Ergebnis:

    Lazy: 3s 98ms
    Nicht-Lazy: 2s 16ms

    Gefällt mir

  4. oliverguhr 4. September 2013 um 12:33 Reply

    Das Feature ist sicher für Objekte gedacht die viel Zeit zum Initialisieren brauchen oder per Default sehr viel Speicher belegen und nicht immer gebraucht werden. Für handelsübliche POCO’s ist es viel Overhead..

    Gefällt mir

    • Uli Armbruster 6. September 2013 um 3:23 Reply

      Inwieweit POCO’s überhaupt in den Container gehören, sei mal dahingestellt. Danke fürs Feedback!

      Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: