Laden...

INotifyPropertyChanged mit Cache ... Vorteil?

Erstellt von TripleX vor 14 Jahren Letzter Beitrag vor 14 Jahren 2.121 Views
TripleX Themenstarter:in
328 Beiträge seit 2006
vor 14 Jahren
INotifyPropertyChanged mit Cache ... Vorteil?

Hallo Gemeinde,

ich habe mir heute überlegt ob es nicht sinnvoll wäre, bei der Implementierung von INotifyPropertyChanged einen "Cache" einzubauen.

Der Vorteil den ich sehe ist der, dass nicht immer ein neues PropertyChangedEventArg erstellt werden muss sobald die Funktion aufgerufen wird.

Nachteil ist dabei aber dass die Klasse etwas "größer" wird (vom Speicherverbrauch) und dass er jetzt bei jeder ChangeNotification erstmal das Dictionary durchsuchen muss:


        private readonly Dictionary<string, PropertyChangedEventArgs> _propertyChangedEventArgsCache = new Dictionary<string, PropertyChangedEventArgs>();
        public event PropertyChangedEventHandler PropertyChanged;
        public void NotifyPropertyChanged(String propertyName)
        {
            PropertyChangedEventArgs args;
            if (!_propertyChangedEventArgsCache.TryGetValue(propertyName, out args))
            {
                args = new PropertyChangedEventArgs(propertyName);
                _propertyChangedEventArgsCache.Add(propertyName, args);
            }

            NotifyPropertyChanged(args);
        }
        public void NotifyPropertyChanged(PropertyChangedEventArgs args)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, args);
            }
        }

Was meint ihr was besser ist - ohne cache oder mit?

€dit: naja nach nem simplen Test hab ich gemerkt dass es ohne Cache viel schneller ist. War wohl ne dumme Idee 😃

MfG TripleX

Träume nicht dein Leben sondern lebe deinen Traum.
Viele Grüße, David Teck

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo TripleX,

ich weiß, dass talla mal den Vorschlag gemacht hatte, für jedes EventArg-Objekt ein statisches Feld zu verwenden. Man braucht ja kein Dictionary, sondern es ist ja schon zur Compilezeit bekannt, welche EventArgs (maximal) benötigt werden.

Das ist dann tatsächlich wohl ein bisschen schneller, als wenn man die EventsArgs jedes Mal neu erstellt. Allerdings ist Performance bei sowas m.E. ein schlechter Ratgeber. Der Geschwindigkeitszuwachs steht in keinem Verhältnis zum höheren Implementierungsaufwand und der höheren Redundanz.

Man muss ja berücksichtigen, dass wenn der Event tatsächlich genutzt wird, der EventHander üblicherweise Reflection benutzen wird, um den geänderten Wert auszulesen und das ist dann immer die Stelle, die die Gesamtpeformance bestimmt. Da fällt es dann nicht mehr ins Gewicht, ob beim Auslösen des Events selbst ein paar Taktzyklen mehr oder weniger benötigt wurden.

herbivore

308 Beiträge seit 2005
vor 14 Jahren

Hallo TripleX,

grundsätzlich ich schließe mich Herbivore an.

Optimierungen würde ich auch (wenn überhaupt) eher in den Aufruf von NotifyPropertyChange legen als in die Methode selber.

z.B. den PropertyName als "internal" zu übergeben.
Also NotifyPropertyChanged so aufrufen:


NotifyPropertyChanged(String.Intern("PropName";));

Oder eine Hilfsklasse mit den Statischen Instanzen der EventArgs:


public static class ProperyChangeArgs
{
public static System.ComponentModel.PropertyChangedEventArgs ItemsArgs = new System.ComponentModel.PropertyChangedEventArgs("Items";);
public static System.ComponentModel.PropertyChangedEventArgs CountArgs = new System.ComponentModel.PropertyChangedEventArgs("Items";);
// ....
}
// Aufruf
NotifyPropertyChanged(ProperyChangeArgs.ItemsArgs);

Aber wie Herbivore schon sagte, das ist Mikrooptimierung an einer Stelle, wo es nichts (oder nur sehr wenig) brint.

F
10.010 Beiträge seit 2004
vor 14 Jahren

Es bringt nicht nur nichts, es ist auch gefährlich.

Danach benutzt jede Routine genau dieses EventArg, was bei Multithreading
dann zu schlecht zu findenden fehlern führt.

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo FZelle,

Danach benutzt jede Routine genau dieses EventArg, was bei Multithreading dann zu schlecht zu findenden fehlern führt.

da die EventsArgs imuttable sind, sehe ich keine Probleme.

Es bringt nicht nur nichts, es ist auch gefährlich.

Genau, gefährlich ist die zusätzliche Redundanz wie man sieht:

public static System.ComponentModel.PropertyChangedEventArgs ItemsArgs = new System.ComponentModel.PropertyChangedEventArgs("Items";);  
public static System.ComponentModel.PropertyChangedEventArgs CountArgs = new System.ComponentModel.PropertyChangedEventArgs("Items";); // Copy&Paste-Fehler (Items statt Count)  

herbivore

1.564 Beiträge seit 2007
vor 14 Jahren

Hallo TripleX

Ich schließe mich den anderen an. Das cachen der EventArgs bringt zwar einen gewissen Performance-Vorteil der jedoch in den meisten Fällen in der Applikation nicht wirklich merkbar sein dürfte.

Worum geht's dir denn genau? Wenn du einen bestimmen Fall hast der potentiell zu Performance-Problemen führen kann, beschreibe den doch mal kurz.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

TripleX Themenstarter:in
328 Beiträge seit 2006
vor 14 Jahren

danke für eure Antworten.

Träume nicht dein Leben sondern lebe deinen Traum.
Viele Grüße, David Teck

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo zusammen,

mittlerweile gibt es auch einen Artikel zu dem Thema, wie man INotifyPropertyChanged (am besten) implementiert: [Artikel] INotifyPropertyChanged implementieren.

herbivore