.Net 2.0

Objekte rechtzeitig erzeugen - aber nicht alle auf einmal!

Jochen — Wed, 14 Feb 2007 15:08:10 GMT

Nach längerer Blogging-Abstinenz gibt es nun endlich mal wieder einen neuen Eintrag. Außerdem bin ich voller Hoffnung, dass ich nun wieder öfters Zeit zum Bloggen finde ;-)

Heute möchte ich das Konzept des letzten Eintrags ("Objekte rechtzeitig erzeugen") ein wenig verbessern. In diesem Eintrag ging es darum, dass viele Algorithmen ganz schnell eine große Menge von Objekten eines bestimmten Typs für ihre Berechnungen brauchen. Um so schneller diese erzeugt werden, um so schneller läuft der Algorithmus. Optimal wäre es also, wenn die Objekte bereits existieren. Genau das macht die in diesem letzten Blog-Eintrag erstellte Klasse - sie erzeugt Objekte zu einem Zeitpunkt, zu dem die dafür benötigte Rechenleistung nicht ins Gewicht fällt.

Diese Klasse hat allerdings einen Nachteil: Alle benötigten Objekte werden auf einmal erzeugt. Das heißt, dass zu irgendeinem Zeitpunkt richtig viel Rechenpower verbraucht wird. Besser wäre es, wenn die Objekte alle schön nacheinander über einen größeren Zeitraum verteilt erzeugt werden. Während des normalen Programmablaufs einer WinForms-Anwendung würde es ja nicht stören, wenn einfach ein paar mal pro Sekunde einige wenige Objekte angelegt werden. Wird dann nach 5 Minuten der Rechen- (und Speicher- ) intensive Algorithmus gestartet, sind dann auch so die nötigen Objekte bereits vorhanden.

Die unten gezeigte ObjectCreator-Klasse implementiert solch ein Verhalten. Sie bedient sich hierzu der System.Windows.Timer-Klasse, welche in einem festen Intervall eine Methode von ObjectCreator aufruft. Zu diesen Zeitpunkten werden dann einige der verwalteten Objekte erstellt:

class ObjectCreator<TargetType> where TargetType : class, new()
    {
        // in diesem Stack werden die Objekte gespeichert
        protected Stack<TargetType> mObjects = new Stack<TargetType>();
        // der Timer, um regelmäßig Objekte zu erzeugen
        protected Timer mTimer = null; 
        // wie viele Objekte sollen in jedem Intervall erzeugt werden?
        protected int mNumObjPerTick = 1;
        // wie viele Objekte sollen insgesamt erzeugt werden?
        protected int mMaxObjs = 1000;

        // Ermöglicht dem User, ein Maximum an verwalteten Objekten zu setzen / lesen
        public int MaxObjects
        {
            get { return this.mMaxObjs; }
            set { if (value > 0) this.mMaxObjs = value; }
        }

        // Anzahl aktuell verfügbarer Objekte
        public int CountCurrentObjects
        {
            get { return this.mObjects.Count; }
        }
        
        // Konstruktor, initialisiert den Timer
        public ObjectCreator()
        {
            mTimer = new Timer();
            mTimer.Enabled = false;
            mTimer.Tick += new EventHandler(mTimer_Tick);
        }

        // ein Objekt wird erstellt und auf dem Stack abgelegt
        public void CreateObject()
        {
            TargetType tt = new TargetType();
            mObjects.Push(tt);
        }

        // gibt ein Objekt zurück und entfernt es aus dem Stack
        public TargetType GetObject()
        {
            if (mObjects.Count > 0)
                return mObjects.Pop();
            else return new TargetType();
        }

        // aktiviert das automatischen Erzeugen von 
        // NumObjObjekten alle MilliSecs Millisekunden
        public void EnableAutoCreation(int MilliSecs, int NumObj)
        {
            if (MilliSecs > 0 && NumObj > 0 && this.mObjects.Count < this.mMaxObjs)
            {
                this.mTimer.Interval = MilliSecs;
                this.mNumObjPerTick = NumObj;
                this.mTimer.Enabled = true;
            }
        }

        // deaktiviert die automatische Erzeugung wieder
        public void DisableAutoCreation()
        {
            this.mTimer.Enabled = false;
        }

        // wird vom Timer alle MilliSecs Millisekunden aufgerufen
        void mTimer_Tick(object sender, EventArgs e)
        {
            for (int i = 0; i < this.mNumObjPerTick; i++)
            {
                this.CreateObject();
            }
        }
    }

Diese Implementierung verwendet einen Stack, um die erzeugten Objekte zwischenzuspeichern. Denkbar sind auch Ansätze mit anderen Container-Klassen, gerade auch ein Array kann sehr sinnvoll sein, da man sich bei geschickter Implementierung die Abfrage von "Count" in GetObject() sparen kann.

Die Klasse ist außerdem generisch, kann also zum frühzeitigen erzeugen aller Datentypen verwendet werden, die selbst ein Referenztyp sind und über einen Konstruktor verfügen. Ausgeschlossen sind hiervon die integralen Datentypen wie beispielsweise int, float, etc. Hierfür müßte man die Implementierung minimal abändern.

Grundsätzlich sollte man solche Klassen allerdings nur dann verwenden, wenn man wirklich viele Objekte verwendet, die auch noch eine gewisse Größe aufweisen. Bitmaps, Texturen, große Strings aber auch Klassen, die viele Membervariablen haben wären sinnvolle Beispiele. Bei der Anwendung sollte man auf jeden Fall testen, ob sich ein Geschwindigkeitsvorteil ergibt. Ist das Problem zu "gering", kann der Versuch durchaus nach hinten gehen, da der Verwaltungsaufwand nicht unerheblich ist. Bei großen Datenmengen kann man allerdings eine Geschwindigkeitssteigerung von Faktor 10 oder mehr verbuchen.

Objekte rechtzeitig erzeugen

Jochen — Fri, 08 Sep 2006 13:05:34 GMT

Oftmals kommt man als Entwickler in die Verlegenheit, dass große Mengen von Objekten in kurzer Zeit erstellt werden müssen. Ein gutes Beispiel hierfür sind Algorithmen, welche während ihrer Laufzeit viele Objekte benötigen um Zustände und Zwischenergebnisse zu speichern.

Üblicherweise werden diese Objekte genau zu dem Zeitpunkt erstellt, zu dem sie auch benötigt werden, also mitten im Algorithmus. Das Erzeugen dieser Objekte kann allerdings recht teuer sein, wenn man bedenkt, dass die .NET Runtime hierzu erst passenden Speicher finden und reservieren muss.
Die Anzahl der verwendeten Objekte steht meist in Relation zu der Problemgröße, beispielsweise der Anzahl an untersuchten Dateien, der Größe eines Eingabearrays oder Ähnlichem. Hierdurch hat man meist schon vor dem Start des Algorithmus eine Ahnung, wie viele Objekte wohl benötigt werden. Dieses Wissen möchten wir uns hier nun zu Nutze machen.

Weiß man nämlich bereits vorab, wie viele Objekte benötigt werden, kann man diese bereits vor dem Ablauf des Algorithmus anlegen und die eigentliche Rechenzeit des Algorithmus somit verkürzen. Nehmen wir einmal an, Ihr Algorithmus würde während seiner Laufzeit viele Objekte des folgenden Typs benötigen:

class MemoryChunk
{
    public int[] iData = new int[100];
}

Diese Klasse ist zwar recht unkompliziert, verlangt der .NET-Runtime jedoch einiges ab. Für eine Anwendung wäre es ein deutlicher Vorteil, wenn das erstellen dieser „Speicherklumpen“ bereits vorbereitet werden könnte.

Zu diesem Zweck erstellen wir eine weitere Klasse, den ObjectCreator:

class ObjectCreator<TargetType> where TargetType : class , new()
{
    private TargetType[] mObjects;

    int mIndex = 0;

    public ObjectCreator()
    {
    }

    public void CreateObjects(int iCount)
    {
        if (iCount > 0)
        {
            mIndex = iCount - 1;

            mObjects = new TargetType[iCount];

            for (int i = 0; i < iCount; i++)
            {
                TargetType obj = new TargetType();
                mObjects[i] = obj;
            }
        }
    }

    public TargetType NewObject()
    {
        if (mIndex > 0)
        {
            TargetType obj = this.mObjects[mIndex];
            mIndex--;
            return obj;
        }
        else return null;
        // oder: else return new TargetType();
    }
}

Wie Sie sehen handelt es sich hierbei um eine generische Klasse. TargetType gibt hierbei den Typ der zu erstellenden Objekte an, beispielsweise MemoryChunk. Durch Aufruf der Methode CreateObjects(AnzahlObj) können Sie ObjectCreator dazu veranlassen, AnzahlObj Objekte anzulegen. Durch Aufruf der Methode NewObject wird nun nach und nach je eines dieser Objekte zurückgegeben.

Die Anwendung der Klasse liegt nun auf der Hand: Wissen Sie beispielsweise, dass Ihr (gleich startender) Algorithmus 800 MemoryChunk-Objekte benötigt, erstellen Sie eine Instanz der Klasse ObjectCreator und rufen CreateObjects auf:

ObjectCreator<MemoryChunk> Creator = new ObjectCreator<MemoryChunk>();
Creator.CreateObjects(800);

Alle Codezeilen, in denen Sie innerhalb des Algorithmus ein MemoryChunk-Objekt erstellen, z.B. durch:

MemoryChunk mem = new MemoryChunk();

können Sie nun durch den folgenden Aufruf ersetzen:

MemoryChunk mem = Creator.NewObject();

Da die hier zurückgegebenen Objekte bereits existieren, werden Sie durch eine deutlich beschleunigte Laufzeit belohnt.

Nun kann man richtigerweise einwenden, dass die Objekte so oder so erstellt werden müssen, in der Summe sollte der Aufwand daher gleich bleiben. Dies ist so sicher richtig, allerdings gibt es viele Situationen, in denen man die „gesammelte“ Objekterstellung in Zeiten des Leerlaufs unterbringen kann. Nehmen Sie beispielsweise an, der Anwender fügt Einträge in einer Liste ein, welche anschließend von einem Algorithmus verarbeitet werden sollen. Während der Anwender den Mauszeiger zum Menüpunkt des Algorithmus bewegt, besteht genug Zeit, die nötigen Objekte vorab zu erstellen und die Wartezeit aufgrund der Abarbeitung für den Anwender zu minimieren.

Schattenpolymorphie

Jochen — Fri, 08 Sep 2006 08:17:34 GMT

Seit Version 6.0 hat sich Visual Basic deutlich weiterentwickelt. Hierbei fällt einem vor allem die nun (endlich) richtige Objektorientierung auf.

Inzwischen dürften wohl die meisten Visual Basic (2005) Programmierer mit den grundlegenden Mechanismen der Objektorientierung - Kapselung, Vererbung und Polymorphie - vertraut sein. Aber es gibt noch einige wenig bekannte Mechanismen, welche in Ausnahmesituationen recht hilfreich sein können.

Ein solcher Mechanismus ist "Shadowing". Stellen Sie sich vor, Sie haben eine Klasse A, welche eine Methode "Method()" enthällt. Der Aufruf von Method() erzeugt folgende Ausgabe:

"Eine Nachricht von Klasse A!"

Der passende Code würde so aussehen:

Class A
Public Overridable Sub MyMethod()
       Console.WriteLine("Eine Nachricht von Klasse A!")
End Sub
End Class

Nun schreiben Sie eine weitere Klasse namens B, welche von A erbt. Sie überschreiben die Methode "Method()", so dass diese nun folgende Ausgabe vornimmt:

"Eine Nachricht von Klasse B!"

Diese würde wie folgt aussehen:

Class B : Inherits A
    Public Overrides Sub MyMethod()
        Console.WriteLine("Eine Nachricht von Klasse B!")
End Sub
End Class

Nun könten Sie folgendes tun:

Dim a As New A
a.Method()

Dim b As New B
b.Method()

a = b
a.Method()

Die Ausgabe wäre dank Polymorphie folgende:

"Eine Nachricht von Klasse A!"
"Eine Nachricht von Klasse B!"
"Eine Nachricht von Klasse B!"

Was aber, wenn Sie möchten, dass sich ein Objekt sich wie der Typ verhällt, den die darauf zeigende Referenz hat? Hierzu können Sie sich des "Shadows" Schlüsselwortes bedienen. Schreiben Sie hierzu die Klasse B wie folgt:

Class B : Inherits A
Public Shadows Sub MyMethod()
        Console.WriteLine("Eine Nachricht von Klasse B!")
End Sub
End Class

Die Ausgabe des Testcodes sieht nun wie folgt aus:

"Eine Nachricht von Klasse A!"
"Eine Nachricht von Klasse B!"
"Eine Nachricht von Klasse A!"

Shadows bewirkt also, das bei Methodenaufrufen durch eine "A"-Referenz, die Methode der A-Klasse aufgerufen wird, während bei einer "B"-Referenz die Methode von B genommen wird. Man könnte Shadows sozusagen auch als "Antipolymorphie" bezeichnen.

Nun, wann braucht man Shadows? Eigentlich sollte man es gar nicht benötigen, wenn Sie Shadows ernsthaft nutzen deutet dies meist auf einen Design-Fehler hin.

Allerdings gibt es einige wenige Situationen, in denen es sich durchaus als nützlich erweist. Stellen Sie sich vor, Sie entwickeln ein Control, welches andere Entwickler via Visual Studio Designer auf ein Form ziehen können. Anschließend kann der Entwickler via Properties Window die Eigenschaften des Controls bearbeiten.
Nun kann es passieren, dass dieses Control im Properties Window Eigenschaften anbietet, welche es von einer Basisklasse geerbt hat. Sie möchten diese dem Entwickler in Ihrem Control aber nicht anbieten. Durch Shadows können Sie solche Eigenschaften "verstecken", indem Sie beispielsweise das [Browsable(false)] Attribut anhängen.

An diesem Beispiel erkennt man aber schon, dass Shadows eher in Randsituationen benötigt wird und nicht in einem ordentlichen, objektorientierten Entwurf. Hier sollten Sie wirklich Abstand von der "dunklen Seite der Polymorphie" halten...

Das My Schlüsselwort in Visual Basic .NET

Jochen — Tue, 05 Sep 2006 14:21:34 GMT

Zum Leidwesen von Microsoft hat sich herausgestellt, dass extrem viele Visual Basic Programmierer den Sprung nach .NET verpasst haben. Die meisten hiervon absichtlich. Der Grund? Visual Basic .NET ist zu kompliziert, der Umstieg auf das (im Vergleich zur VB Runtime) komplexere .NET Framework dauert zu lange und lohnt sich nicht.

Mit Visual Basic 2005 will Microsoft dies ändern und die Stärke des "alten VB" wieder in den Vordergrund stellen: Einfachheit.

Ein großes Problem bei .NET stellen (für Visual Basic Veteranen) die vielen verschachtelten Namespaces dar. Unter Visual Basic 5/6 gab es eine Handvoll von Namespaces, oder sagen wir lieber "Gruppen", in denen eingentlich die komplette VB-Runtime Platz fand und trotzdem nicht unübersichtlich wurde.

Aber auch die nun erzwungene und Lehrbuch-konforme Objektorientierung stößt bei vielen "VBlern" auf Unverständniss. Erinnen Sie sich an die Forms aus VB 5/6? Klassen waren das ja eigentlich nicht wirklich, von der Verwendung her eher Objekte... aber naja... mehrere Instanzen konnte man dann ja doch erstellen und überhaupt... es war irgendwie komisch, aber funktioniert hat's trotzdem... Nur verständlich dass der Umstieg auf UML-konforme Objektorientierung da ein Problem darstellt.

"Was machen wir nun, um aus dieser Kiste wieder heil herauszukommen?", dachten sich nun die VB-Designer bei Microsoft. Und die Lösung heißt "My".

My wenn Sie "My" gefolgt von "." in Visual Studio 2005 eintippen begrüßt Sie ein IntellySense Fenster, welches erst mal vermuten läßt, dass es sich bei My um einen Namepspace handelt. Ist es eigentlich auch! My soll die wichtigsten Funktionen aus dem .NET Framework herauspicken und zentral zur Verfügung stellen. Sie finden in My wiederum Namespaces wie z.B.:

Application
Computer
Settings
User

und einige mehr. Diese Namespaces fassen einige der wichtigsten Funktionen und Klassen kurz zusammen, um diese ohne große Umwege zugänglich zu machen.

Sie möchten zum Beispiel auf den aktuell angemeldeten Benutzernamen zugreifen können? Kein Problem:

My.User.Name

Einfacher ging's auch mit dem alten VB nicht...

Und um nochmal auf die Forms zurückzukommen: Ihre Fenster finden Sie jetzt alle direkt unter My.Forms. Das erinnert schon ein wenig an frühere Visual Basic Anwendungen, oder?

Fehlermeldung "Assembly 'name.dll' is required to be strongly named"

Jochen — Mon, 04 Sep 2006 10:33:21 GMT

Beim Versuch, eine Assembly in den Global Assembly Cache (GAC) zu kopieren, erscheint die Fehlermeldung "Assembly 'name.dll' is required to be strongly named".
Ursache:
Nur Assemblys mit einem strong name dürfen im GAC platziert werden. Hierzu muss ein public / private Key generiert werden um die Assembly zu signieren.
Lösung:
Geben Sie "sn -k keyfile.snk" am Visual Studio 2003/2005 Command Prompt ein, wobei keyfile.snk den Dateinamen angibt, unter dem der erzeugte Key gespeichert wird.
Visual Studio .NET 2003:
Öffnen Sie Ihr Visual Studio Projekt und die Datei AssemblyInfo.cs und navigieren Sie zu folgender Zeile:
[assembly: AssemblyKeyFile("")]
Fügen Sie hier den Pfad zum generierten Key ein und kompilieren Sie Ihr Projekt neu.
Visual Studio 2005:
Öffnen Sie die Projekt Eigenschaften und wählen Sie den Punkt "Signing".
Wählen Sie die Option "Sign the assembly" und wählen Sie die Datei mit Ihrem Key. Klicken Sie 'OK' und kompilieren Sie Ihr Projekt neu. Nun sollten Sie Ihre Assembly im GAC platzieren können.